{"owner":"toss","repo":"es-toolkit","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","CLAUDE.md"],"skills":{"AGENTS.md":"# es-toolkit LLM coding agent instructions\n\nThis file gives LLM coding agents the context they need to contribute to es-toolkit. Read it before making changes, and follow it together with [`.github/CONTRIBUTING.md`](./.github/CONTRIBUTING.md) (and its translations).\n\n## Project overview\n\nes-toolkit is a modern, high-performance JavaScript utility library with a small bundle size and strong type annotations. It provides a curated set of utilities that are difficult to write with built-in JavaScript methods but are commonly needed in real-world projects, such as [`delay`](https://es-toolkit.dev/reference/promise/delay.html), [`windowed`](https://es-toolkit.dev/reference/array/windowed.html), [`keyBy`](https://es-toolkit.dev/reference/array/keyBy.html), [`mapValues`](https://es-toolkit.dev/reference/object/mapValues.html), [`camelCase`](https://es-toolkit.dev/reference/string/camelCase.html), and [`toSnakeCaseKeys`](https://es-toolkit.dev/reference/object/toSnakeCaseKeys.html).\n\nThe library is split into two entry points:\n\n- **`es-toolkit`** — the strict, opinionated main library. Focused on the 85% use case with a simple interface, no complex options, and modern JavaScript semantics.\n- **`es-toolkit/compat`** — a Lodash-compatible variant intended to make migration from Lodash easy. Compat is feature-complete; only behavior fixes against Lodash are accepted, not new functions.\n\nes-toolkit is a zero-dependency library and ships with no runtime dependencies.\n\n## Development environment\n\n- **Primary environment**: Node.js v24 (see `.nvmrc` for the exact version)\n- **Recommended editor**: Visual Studio Code\n- **Package manager**: Yarn v4, installed via [Corepack](https://yarnpkg.com/getting-started/install). See [the package manager section in CONTRIBUTING.md](./.github/CONTRIBUTING.md#package-manager) for details.\n\nTo get started:\n\n```bash\ncorepack enable\nyarn install\n```\n\nCommon commands:\n\n```bash\nyarn vitest run                   # Run all tests\nyarn vitest run src/array/chunk   # Run tests for a specific function\nyarn lint                         # ESLint\ntsc --noEmit                      # Typecheck\n```\n\n## Repository structure\n\n```\nsrc/\n  {category}/{fn}.ts          Implementation for the main `es-toolkit` library\n  {category}/{fn}.spec.ts     Unit tests (vitest)\n  compat/{category}/{fn}.ts   Lodash-compatible variant under `es-toolkit/compat`\n  index.ts                    Top-level barrel re-exports\n  {category}/index.ts         Per-category barrel re-exports\ndocs/\n  reference/{category}/{fn}.md          English reference docs\n  ko/reference/{category}/{fn}.md       Korean reference docs\n  ja/reference/{category}/{fn}.md       Japanese reference docs\n  zh_hans/reference/{category}/{fn}.md  Simplified Chinese reference docs\nbenchmarks/                   Vitest benchmark suite\ntests/types/                  Type tests comparing `es-toolkit/compat` with `@types/lodash` (run with `yarn workspace type-tests test`)\n.github/CONTRIBUTING.md       Contribution guide (English / Korean / Simplified Chinese)\nCHANGELOG.md                  User-facing changelog\n```\n\nCategories include `array`, `bigint`, `function`, `math`, `object`, `predicate`, `promise`, `set`, `string`, `util`, `error`, and `map`.\n\n## Principles\n\nes-toolkit values **performance**, **simplicity**, and **detailed documentation** over a wide surface area of features and options.\n\n- **Performance**: every function should match or beat alternative libraries. New features must come with benchmarks.\n- **Simplicity**: provide the simplest interface for the 85% use case; do not add complex options for every edge case.\n- **Don't reimplement modern JS**: skip functions that are already covered by built-ins (`Array.isArray`, `Number.isNaN`, `Math.min`, `typeof value === 'number'`, etc.) or by TC39 proposals at Stage 3 or above.\n- **Accurate types**: match the inference behavior of TypeScript's `strict` mode.\n- **Two entry points, two policies**: `es-toolkit` is the opinionated API; `es-toolkit/compat` mirrors Lodash for migration. Compat is feature-complete — only behavior fixes against Lodash are accepted, not new functions.\n\nFor the full text, see [Section 1 of CONTRIBUTING.md](./.github/CONTRIBUTING.md#1-our-design-principles).\n\n## Coding conventions\n\n- Prefer `for` loops over `reduce`. Local mutability is fine.\n- Prefer built-in JavaScript over custom helpers (`Array.isArray()` over `isArray()`, `typeof value === 'string'` over `isString()`).\n- Use short type parameter names: `T` for elements, `K` for keys, `E` for errors.\n- Use `readonly T[]` for array parameters that are not mutated.\n- Write detailed JSDoc with `@template`, `@param`, `@returns`, `@throws`, and `@example` blocks.\n\nFor the full text, see [Section 2 of CONTRIBUTING.md](./.github/CONTRIBUTING.md#2-coding-conventions).\n\n## Development workflow\n\nWhen adding or changing a function, follow this order:\n\n1. **Add the implementation** under `src/{category}/{fn}.ts` (or `src/compat/{category}/{fn}.ts` for compat-only fixes). Re-export it from `src/{category}/index.ts` and `src/index.ts`.\n2. **Add unit tests** with vitest in `src/{category}/{fn}.spec.ts`. Cover the happy path, edge cases (empty input, `null`/`undefined`, large input), and any Lodash-specific behavior in compat.\n3. **Run the unit tests**:\n   ```bash\n   yarn vitest run src/{category}/{fn}\n   ```\n   Then run the full suite (`yarn vitest run`), `yarn lint`, and `tsc --noEmit` before opening the PR.\n4. **Add documentation in all four languages** under `docs/`:\n\n   - `docs/reference/{category}/{fn}.md` (English)\n   - `docs/ko/reference/{category}/{fn}.md` (Korean, 해요체)\n   - `docs/ja/reference/{category}/{fn}.md` (Japanese)\n   - `docs/zh_hans/reference/{category}/{fn}.md` (Simplified Chinese)\n\n   See `docs/CLAUDE.md` for translation tables, and the [Writing Documentation section in CONTRIBUTING.md](./.github/CONTRIBUTING.md#5-writing-documentation) for the template and placeholder rules.\n\n## Documentation standards\n\n- Include JSDoc comments for every public API. Keep `@template`, `@param`, `@returns`, `@throws`, and `@example` up to date.\n- Update the documentation whenever you change a public API. Keep all four language versions in sync — never leave one stale.\n- Include realistic examples for new features. Prefer descriptive variable names over magic values so readers can infer the interface from the example.\n\n## Pull request standards\n\nBefore opening a pull request, check [what we accept](./.github/CONTRIBUTING.md#41-what-we-accept). New functions need an accepted discussion first, performance work needs benchmark results, Lodash behavior fixes need a test that fails without the change, and refactoring-only changes are not accepted.\n\nPR titles follow `<type>[function names]: <description>`. See [Section 4 of CONTRIBUTING.md](./.github/CONTRIBUTING.md#4-pull-requests) for the type list.\n\nUse the following template for the PR body:\n\n```markdown\n## Summary\n\n{Related issues if any}\n{Concise summary}\n\n## Changes\n\n{Concise explanation of the code changes, in bullet points}\n\n## Benchmark results\n\n{Only for performance changes: benchmark output for `main` and for this branch. Remove this section otherwise.}\n```\n\nDo not paste test output into the PR body. CI runs the test suite on every pull request, so the results are already visible there. Benchmarks are the exception—nothing in CI runs them, so a performance change has to bring its own numbers.\n\n## Adding dependencies\n\nes-toolkit is a **zero-dependency** library. Do not add anything to `dependencies` or `peerDependencies`. Only `devDependencies` are acceptable, and even there, prefer to avoid new packages unless they are clearly necessary for tooling.\n\n## Changelog\n\nUser-facing changes go into [`CHANGELOG.md`](./CHANGELOG.md). Keep the file readable as a release notes document for users, not as a commit log.\n\nConventions:\n\n- **Reverse chronological order** — newest version at the top.\n- Each version is a heading: `## Version v{version}`, followed by a `Released on {date}.` line.\n- Use `-` for list items. Wrap lines at roughly 80 columns and indent continuations with 4 spaces.\n- Write **user-facing descriptions**: what changed, why it matters, and what users should do. Avoid implementation jargon.\n- Reference PRs with `[#123]` markers inline. When a section has many references, you may add reference link definitions at the end of that section in the form `[#123]: https://github.com/toss/es-toolkit/pull/123`.\n- For external contributors, credit them on the line: `[#123] by @username`.\n- End each version section with a thank-you line:\n\n  > We sincerely thank @username1, @username2, and @username3 for their contributions. We appreciate your great efforts!\n","CLAUDE.md":"# CLAUDE.md\n\nInstructions for AI assistants working on es-toolkit.\n\n## Language\n\nThis is a global project with users speaking various languages. When producing non-code output (explanations, reviews, reports), respond in the user's preferred language.\n\n## Quick Reference\n\n```bash\ncorepack enable && yarn install   # Setup\nyarn vitest run                   # Tests\nyarn vitest run src/array/chunk   # Test specific function\nyarn lint                         # ESLint\ntsc --noEmit                      # Typecheck\n```\n\n## Structure\n\n```\nsrc/{category}/{fn}.ts            # Implementation (array, bigint, function, math, object, predicate, promise, set, string, util, error, map)\nsrc/{category}/{fn}.spec.ts       # Tests (vitest)\nsrc/compat/{category}/{fn}.ts     # Lodash-compatible variant\ntests/types/compat.spec-d.ts      # Type tests against @types/lodash (yarn workspace type-tests test)\ndocs/reference/{category}/{fn}.md           # English\ndocs/ko/reference/{category}/{fn}.md        # Korean\ndocs/ja/reference/{category}/{fn}.md        # Japanese\ndocs/zh_hans/reference/{category}/{fn}.md   # Chinese\n```\n\n## Design Principles\n\n- **Performance**: Must match or beat lodash.\n- **Simplicity**: Simplest interface for the 85% use case. No complex options.\n- **Don't implement**: Functions replaceable by modern JS (`Array.isArray`, `Number.isNaN`, `Math.min`), or TC39 Stage 3+ proposals.\n- **es-toolkit vs compat**: `es-toolkit` is the strict, opinionated API. `es-toolkit/compat` matches lodash behavior exactly for migration. Compat is feature-complete — no new functions are being added. Only behavior inconsistency fixes against lodash are accepted.\n- **What we accept**: New functions need an accepted [discussion](https://github.com/toss/es-toolkit/discussions/new?category=ideas) first, performance work needs benchmark results, and refactoring-only changes are not accepted. See [`.github/CONTRIBUTING.md`](./.github/CONTRIBUTING.md#41-what-we-accept).\n\n## Coding Conventions\n\n- `for` loops over `reduce` (local mutation is fine)\n- Built-in JS over custom helpers (`Array.isArray()`, not `isArray()`)\n- Type params: `T` elements, `K` keys, `E` errors\n- `readonly T[]` for array params that aren't mutated\n- Detailed JSDoc with `@template`, `@param`, `@returns`, `@throws`, `@example`\n\n## New Function Checklist\n\n1. `src/{category}/{fn}.ts` — Implementation\n2. `src/{category}/{fn}.spec.ts` — Tests\n3. Re-export in `src/{category}/index.ts` and `src/index.ts`\n4. Docs in all 4 languages (see `docs/CLAUDE.md` for templates)\n"},"files":{"AGENTS.md":"# es-toolkit LLM coding agent instructions\n\nThis file gives LLM coding agents the context they need to contribute to es-toolkit. Read it before making changes, and follow it together with [`.github/CONTRIBUTING.md`](./.github/CONTRIBUTING.md) (and its translations).\n\n## Project overview\n\nes-toolkit is a modern, high-performance JavaScript utility library with a small bundle size and strong type annotations. It provides a curated set of utilities that are difficult to write with built-in JavaScript methods but are commonly needed in real-world projects, such as [`delay`](https://es-toolkit.dev/reference/promise/delay.html), [`windowed`](https://es-toolkit.dev/reference/array/windowed.html), [`keyBy`](https://es-toolkit.dev/reference/array/keyBy.html), [`mapValues`](https://es-toolkit.dev/reference/object/mapValues.html), [`camelCase`](https://es-toolkit.dev/reference/string/camelCase.html), and [`toSnakeCaseKeys`](https://es-toolkit.dev/reference/object/toSnakeCaseKeys.html).\n\nThe library is split into two entry points:\n\n- **`es-toolkit`** — the strict, opinionated main library. Focused on the 85% use case with a simple interface, no complex options, and modern JavaScript semantics.\n- **`es-toolkit/compat`** — a Lodash-compatible variant intended to make migration from Lodash easy. Compat is feature-complete; only behavior fixes against Lodash are accepted, not new functions.\n\nes-toolkit is a zero-dependency library and ships with no runtime dependencies.\n\n## Development environment\n\n- **Primary environment**: Node.js v24 (see `.nvmrc` for the exact version)\n- **Recommended editor**: Visual Studio Code\n- **Package manager**: Yarn v4, installed via [Corepack](https://yarnpkg.com/getting-started/install). See [the package manager section in CONTRIBUTING.md](./.github/CONTRIBUTING.md#package-manager) for details.\n\nTo get started:\n\n```bash\ncorepack enable\nyarn install\n```\n\nCommon commands:\n\n```bash\nyarn vitest run                   # Run all tests\nyarn vitest run src/array/chunk   # Run tests for a specific function\nyarn lint                         # ESLint\ntsc --noEmit                      # Typecheck\n```\n\n## Repository structure\n\n```\nsrc/\n  {category}/{fn}.ts          Implementation for the main `es-toolkit` library\n  {category}/{fn}.spec.ts     Unit tests (vitest)\n  compat/{category}/{fn}.ts   Lodash-compatible variant under `es-toolkit/compat`\n  index.ts                    Top-level barrel re-exports\n  {category}/index.ts         Per-category barrel re-exports\ndocs/\n  reference/{category}/{fn}.md          English reference docs\n  ko/reference/{category}/{fn}.md       Korean reference docs\n  ja/reference/{category}/{fn}.md       Japanese reference docs\n  zh_hans/reference/{category}/{fn}.md  Simplified Chinese reference docs\nbenchmarks/                   Vitest benchmark suite\ntests/types/                  Type tests comparing `es-toolkit/compat` with `@types/lodash` (run with `yarn workspace type-tests test`)\n.github/CONTRIBUTING.md       Contribution guide (English / Korean / Simplified Chinese)\nCHANGELOG.md                  User-facing changelog\n```\n\nCategories include `array`, `bigint`, `function`, `math`, `object`, `predicate`, `promise`, `set`, `string`, `util`, `error`, and `map`.\n\n## Principles\n\nes-toolkit values **performance**, **simplicity**, and **detailed documentation** over a wide surface area of features and options.\n\n- **Performance**: every function should match or beat alternative libraries. New features must come with benchmarks.\n- **Simplicity**: provide the simplest interface for the 85% use case; do not add complex options for every edge case.\n- **Don't reimplement modern JS**: skip functions that are already covered by built-ins (`Array.isArray`, `Number.isNaN`, `Math.min`, `typeof value === 'number'`, etc.) or by TC39 proposals at Stage 3 or above.\n- **Accurate types**: match the inference behavior of TypeScript's `strict` mode.\n- **Two entry points, two policies**: `es-toolkit` is the opinionated API; `es-toolkit/compat` mirrors Lodash for migration. Compat is feature-complete — only behavior fixes against Lodash are accepted, not new functions.\n\nFor the full text, see [Section 1 of CONTRIBUTING.md](./.github/CONTRIBUTING.md#1-our-design-principles).\n\n## Coding conventions\n\n- Prefer `for` loops over `reduce`. Local mutability is fine.\n- Prefer built-in JavaScript over custom helpers (`Array.isArray()` over `isArray()`, `typeof value === 'string'` over `isString()`).\n- Use short type parameter names: `T` for elements, `K` for keys, `E` for errors.\n- Use `readonly T[]` for array parameters that are not mutated.\n- Write detailed JSDoc with `@template`, `@param`, `@returns`, `@throws`, and `@example` blocks.\n\nFor the full text, see [Section 2 of CONTRIBUTING.md](./.github/CONTRIBUTING.md#2-coding-conventions).\n\n## Development workflow\n\nWhen adding or changing a function, follow this order:\n\n1. **Add the implementation** under `src/{category}/{fn}.ts` (or `src/compat/{category}/{fn}.ts` for compat-only fixes). Re-export it from `src/{category}/index.ts` and `src/index.ts`.\n2. **Add unit tests** with vitest in `src/{category}/{fn}.spec.ts`. Cover the happy path, edge cases (empty input, `null`/`undefined`, large input), and any Lodash-specific behavior in compat.\n3. **Run the unit tests**:\n   ```bash\n   yarn vitest run src/{category}/{fn}\n   ```\n   Then run the full suite (`yarn vitest run`), `yarn lint`, and `tsc --noEmit` before opening the PR.\n4. **Add documentation in all four languages** under `docs/`:\n\n   - `docs/reference/{category}/{fn}.md` (English)\n   - `docs/ko/reference/{category}/{fn}.md` (Korean, 해요체)\n   - `docs/ja/reference/{category}/{fn}.md` (Japanese)\n   - `docs/zh_hans/reference/{category}/{fn}.md` (Simplified Chinese)\n\n   See `docs/CLAUDE.md` for translation tables, and the [Writing Documentation section in CONTRIBUTING.md](./.github/CONTRIBUTING.md#5-writing-documentation) for the template and placeholder rules.\n\n## Documentation standards\n\n- Include JSDoc comments for every public API. Keep `@template`, `@param`, `@returns`, `@throws`, and `@example` up to date.\n- Update the documentation whenever you change a public API. Keep all four language versions in sync — never leave one stale.\n- Include realistic examples for new features. Prefer descriptive variable names over magic values so readers can infer the interface from the example.\n\n## Pull request standards\n\nBefore opening a pull request, check [what we accept](./.github/CONTRIBUTING.md#41-what-we-accept). New functions need an accepted discussion first, performance work needs benchmark results, Lodash behavior fixes need a test that fails without the change, and refactoring-only changes are not accepted.\n\nPR titles follow `<type>[function names]: <description>`. See [Section 4 of CONTRIBUTING.md](./.github/CONTRIBUTING.md#4-pull-requests) for the type list.\n\nUse the following template for the PR body:\n\n```markdown\n## Summary\n\n{Related issues if any}\n{Concise summary}\n\n## Changes\n\n{Concise explanation of the code changes, in bullet points}\n\n## Benchmark results\n\n{Only for performance changes: benchmark output for `main` and for this branch. Remove this section otherwise.}\n```\n\nDo not paste test output into the PR body. CI runs the test suite on every pull request, so the results are already visible there. Benchmarks are the exception—nothing in CI runs them, so a performance change has to bring its own numbers.\n\n## Adding dependencies\n\nes-toolkit is a **zero-dependency** library. Do not add anything to `dependencies` or `peerDependencies`. Only `devDependencies` are acceptable, and even there, prefer to avoid new packages unless they are clearly necessary for tooling.\n\n## Changelog\n\nUser-facing changes go into [`CHANGELOG.md`](./CHANGELOG.md). Keep the file readable as a release notes document for users, not as a commit log.\n\nConventions:\n\n- **Reverse chronological order** — newest version at the top.\n- Each version is a heading: `## Version v{version}`, followed by a `Released on {date}.` line.\n- Use `-` for list items. Wrap lines at roughly 80 columns and indent continuations with 4 spaces.\n- Write **user-facing descriptions**: what changed, why it matters, and what users should do. Avoid implementation jargon.\n- Reference PRs with `[#123]` markers inline. When a section has many references, you may add reference link definitions at the end of that section in the form `[#123]: https://github.com/toss/es-toolkit/pull/123`.\n- For external contributors, credit them on the line: `[#123] by @username`.\n- End each version section with a thank-you line:\n\n  > We sincerely thank @username1, @username2, and @username3 for their contributions. We appreciate your great efforts!\n","CLAUDE.md":"# CLAUDE.md\n\nInstructions for AI assistants working on es-toolkit.\n\n## Language\n\nThis is a global project with users speaking various languages. When producing non-code output (explanations, reviews, reports), respond in the user's preferred language.\n\n## Quick Reference\n\n```bash\ncorepack enable && yarn install   # Setup\nyarn vitest run                   # Tests\nyarn vitest run src/array/chunk   # Test specific function\nyarn lint                         # ESLint\ntsc --noEmit                      # Typecheck\n```\n\n## Structure\n\n```\nsrc/{category}/{fn}.ts            # Implementation (array, bigint, function, math, object, predicate, promise, set, string, util, error, map)\nsrc/{category}/{fn}.spec.ts       # Tests (vitest)\nsrc/compat/{category}/{fn}.ts     # Lodash-compatible variant\ntests/types/compat.spec-d.ts      # Type tests against @types/lodash (yarn workspace type-tests test)\ndocs/reference/{category}/{fn}.md           # English\ndocs/ko/reference/{category}/{fn}.md        # Korean\ndocs/ja/reference/{category}/{fn}.md        # Japanese\ndocs/zh_hans/reference/{category}/{fn}.md   # Chinese\n```\n\n## Design Principles\n\n- **Performance**: Must match or beat lodash.\n- **Simplicity**: Simplest interface for the 85% use case. No complex options.\n- **Don't implement**: Functions replaceable by modern JS (`Array.isArray`, `Number.isNaN`, `Math.min`), or TC39 Stage 3+ proposals.\n- **es-toolkit vs compat**: `es-toolkit` is the strict, opinionated API. `es-toolkit/compat` matches lodash behavior exactly for migration. Compat is feature-complete — no new functions are being added. Only behavior inconsistency fixes against lodash are accepted.\n- **What we accept**: New functions need an accepted [discussion](https://github.com/toss/es-toolkit/discussions/new?category=ideas) first, performance work needs benchmark results, and refactoring-only changes are not accepted. See [`.github/CONTRIBUTING.md`](./.github/CONTRIBUTING.md#41-what-we-accept).\n\n## Coding Conventions\n\n- `for` loops over `reduce` (local mutation is fine)\n- Built-in JS over custom helpers (`Array.isArray()`, not `isArray()`)\n- Type params: `T` elements, `K` keys, `E` errors\n- `readonly T[]` for array params that aren't mutated\n- Detailed JSDoc with `@template`, `@param`, `@returns`, `@throws`, `@example`\n\n## New Function Checklist\n\n1. `src/{category}/{fn}.ts` — Implementation\n2. `src/{category}/{fn}.spec.ts` — Tests\n3. Re-export in `src/{category}/index.ts` and `src/index.ts`\n4. Docs in all 4 languages (see `docs/CLAUDE.md` for templates)\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# es-toolkit LLM coding agent instructions\n\nThis file gives LLM coding agents the context they need to contribute to es-toolkit. Read it before making changes, and follow it together with [`.github/CONTRIBUTING.md`](./.github/CONTRIBUTING.md) (and its translations).\n\n## Project overview\n\nes-toolkit is a modern, high-performance JavaScript utility library with a small bundle size and strong type annotations. It provides a curated set of utilities that are difficult to write with built-in JavaScript methods but are commonly needed in real-world projects, such as [`delay`](https://es-toolkit.dev/reference/promise/delay.html), [`windowed`](https://es-toolkit.dev/reference/array/windowed.html), [`keyBy`](https://es-toolkit.dev/reference/array/keyBy.html), [`mapValues`](https://es-toolkit.dev/reference/object/mapValues.html), [`camelCase`](https://es-toolkit.dev/reference/string/camelCase.html), and [`toSnakeCaseKeys`](https://es-toolkit.dev/reference/object/toSnakeCaseKeys.html).\n\nThe library is split into two entry points:\n\n- **`es-toolkit`** — the strict, opinionated main library. Focused on the 85% use case with a simple interface, no complex options, and modern JavaScript semantics.\n- **`es-toolkit/compat`** — a Lodash-compatible variant intended to make migration from Lodash easy. Compat is feature-complete; only behavior fixes against Lodash are accepted, not new functions.\n\nes-toolkit is a zero-dependency library and ships with no runtime dependencies.\n\n## Development environment\n\n- **Primary environment**: Node.js v24 (see `.nvmrc` for the exact version)\n- **Recommended editor**: Visual Studio Code\n- **Package manager**: Yarn v4, installed via [Corepack](https://yarnpkg.com/getting-started/install). See [the package manager section in CONTRIBUTING.md](./.github/CONTRIBUTING.md#package-manager) for details.\n\nTo get started:\n\n```bash\ncorepack enable\nyarn install\n```\n\nCommon commands:\n\n```bash\nyarn vitest run                   # Run all tests\nyarn vitest run src/array/chunk   # Run tests for a specific function\nyarn lint                         # ESLint\ntsc --noEmit                      # Typecheck\n```\n\n## Repository structure\n\n```\nsrc/\n  {category}/{fn}.ts          Implementation for the main `es-toolkit` library\n  {category}/{fn}.spec.ts     Unit tests (vitest)\n  compat/{category}/{fn}.ts   Lodash-compatible variant under `es-toolkit/compat`\n  index.ts                    Top-level barrel re-exports\n  {category}/index.ts         Per-category barrel re-exports\ndocs/\n  reference/{category}/{fn}.md          English reference docs\n  ko/reference/{category}/{fn}.md       Korean reference docs\n  ja/reference/{category}/{fn}.md       Japanese reference docs\n  zh_hans/reference/{category}/{fn}.md  Simplified Chinese reference docs\nbenchmarks/                   Vitest benchmark suite\ntests/types/                  Type tests comparing `es-toolkit/compat` with `@types/lodash` (run with `yarn workspace type-tests test`)\n.github/CONTRIBUTING.md       Contribution guide (English / Korean / Simplified Chinese)\nCHANGELOG.md                  User-facing changelog\n```\n\nCategories include `array`, `bigint`, `function`, `math`, `object`, `predicate`, `promise`, `set`, `string`, `util`, `error`, and `map`.\n\n## Principles\n\nes-toolkit values **performance**, **simplicity**, and **detailed documentation** over a wide surface area of features and options.\n\n- **Performance**: every function should match or beat alternative libraries. New features must come with benchmarks.\n- **Simplicity**: provide the simplest interface for the 85% use case; do not add complex options for every edge case.\n- **Don't reimplement modern JS**: skip functions that are already covered by built-ins (`Array.isArray`, `Number.isNaN`, `Math.min`, `typeof value === 'number'`, etc.) or by TC39 proposals at Stage 3 or above.\n- **Accurate types**: match the inference behavior of TypeScript's `strict` mode.\n- **Two entry points, two policies**: `es-toolkit` is the opinionated API; `es-toolkit/compat` mirrors Lodash for migration. Compat is feature-complete — only behavior fixes against Lodash are accepted, not new functions.\n\nFor the full text, see [Section 1 of CONTRIBUTING.md](./.github/CONTRIBUTING.md#1-our-design-principles).\n\n## Coding conventions\n\n- Prefer `for` loops over `reduce`. Local mutability is fine.\n- Prefer built-in JavaScript over custom helpers (`Array.isArray()` over `isArray()`, `typeof value === 'string'` over `isString()`).\n- Use short type parameter names: `T` for elements, `K` for keys, `E` for errors.\n- Use `readonly T[]` for array parameters that are not mutated.\n- Write detailed JSDoc with `@template`, `@param`, `@returns`, `@throws`, and `@example` blocks.\n\nFor the full text, see [Section 2 of CONTRIBUTING.md](./.github/CONTRIBUTING.md#2-coding-conventions).\n\n## Development workflow\n\nWhen adding or changing a function, follow this order:\n\n1. **Add the implementation** under `src/{category}/{fn}.ts` (or `src/compat/{category}/{fn}.ts` for compat-only fixes). Re-export it from `src/{category}/index.ts` and `src/index.ts`.\n2. **Add unit tests** with vitest in `src/{category}/{fn}.spec.ts`. Cover the happy path, edge cases (empty input, `null`/`undefined`, large input), and any Lodash-specific behavior in compat.\n3. **Run the unit tests**:\n   ```bash\n   yarn vitest run src/{category}/{fn}\n   ```\n   Then run the full suite (`yarn vitest run`), `yarn lint`, and `tsc --noEmit` before opening the PR.\n4. **Add documentation in all four languages** under `docs/`:\n\n   - `docs/reference/{category}/{fn}.md` (English)\n   - `docs/ko/reference/{category}/{fn}.md` (Korean, 해요체)\n   - `docs/ja/reference/{category}/{fn}.md` (Japanese)\n   - `docs/zh_hans/reference/{category}/{fn}.md` (Simplified Chinese)\n\n   See `docs/CLAUDE.md` for translation tables, and the [Writing Documentation section in CONTRIBUTING.md](./.github/CONTRIBUTING.md#5-writing-documentation) for the template and placeholder rules.\n\n## Documentation standards\n\n- Include JSDoc comments for every public API. Keep `@template`, `@param`, `@returns`, `@throws`, and `@example` up to date.\n- Update the documentation whenever you change a public API. Keep all four language versions in sync — never leave one stale.\n- Include realistic examples for new features. Prefer descriptive variable names over magic values so readers can infer the interface from the example.\n\n## Pull request standards\n\nBefore opening a pull request, check [what we accept](./.github/CONTRIBUTING.md#41-what-we-accept). New functions need an accepted discussion first, performance work needs benchmark results, Lodash behavior fixes need a test that fails without the change, and refactoring-only changes are not accepted.\n\nPR titles follow `<type>[function names]: <description>`. See [Section 4 of CONTRIBUTING.md](./.github/CONTRIBUTING.md#4-pull-requests) for the type list.\n\nUse the following template for the PR body:\n\n```markdown\n## Summary\n\n{Related issues if any}\n{Concise summary}\n\n## Changes\n\n{Concise explanation of the code changes, in bullet points}\n\n## Benchmark results\n\n{Only for performance changes: benchmark output for `main` and for this branch. Remove this section otherwise.}\n```\n\nDo not paste test output into the PR body. CI runs the test suite on every pull request, so the results are already visible there. Benchmarks are the exception—nothing in CI runs them, so a performance change has to bring its own numbers.\n\n## Adding dependencies\n\nes-toolkit is a **zero-dependency** library. Do not add anything to `dependencies` or `peerDependencies`. Only `devDependencies` are acceptable, and even there, prefer to avoid new packages unless they are clearly necessary for tooling.\n\n## Changelog\n\nUser-facing changes go into [`CHANGELOG.md`](./CHANGELOG.md). Keep the file readable as a release notes document for users, not as a commit log.\n\nConventions:\n\n- **Reverse chronological order** — newest version at the top.\n- Each version is a heading: `## Version v{version}`, followed by a `Released on {date}.` line.\n- Use `-` for list items. Wrap lines at roughly 80 columns and indent continuations with 4 spaces.\n- Write **user-facing descriptions**: what changed, why it matters, and what users should do. Avoid implementation jargon.\n- Reference PRs with `[#123]` markers inline. When a section has many references, you may add reference link definitions at the end of that section in the form `[#123]: https://github.com/toss/es-toolkit/pull/123`.\n- For external contributors, credit them on the line: `[#123] by @username`.\n- End each version section with a thank-you line:\n\n  > We sincerely thank @username1, @username2, and @username3 for their contributions. We appreciate your great efforts!\n","category":"root","tokens":2183},{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# CLAUDE.md\n\nInstructions for AI assistants working on es-toolkit.\n\n## Language\n\nThis is a global project with users speaking various languages. When producing non-code output (explanations, reviews, reports), respond in the user's preferred language.\n\n## Quick Reference\n\n```bash\ncorepack enable && yarn install   # Setup\nyarn vitest run                   # Tests\nyarn vitest run src/array/chunk   # Test specific function\nyarn lint                         # ESLint\ntsc --noEmit                      # Typecheck\n```\n\n## Structure\n\n```\nsrc/{category}/{fn}.ts            # Implementation (array, bigint, function, math, object, predicate, promise, set, string, util, error, map)\nsrc/{category}/{fn}.spec.ts       # Tests (vitest)\nsrc/compat/{category}/{fn}.ts     # Lodash-compatible variant\ntests/types/compat.spec-d.ts      # Type tests against @types/lodash (yarn workspace type-tests test)\ndocs/reference/{category}/{fn}.md           # English\ndocs/ko/reference/{category}/{fn}.md        # Korean\ndocs/ja/reference/{category}/{fn}.md        # Japanese\ndocs/zh_hans/reference/{category}/{fn}.md   # Chinese\n```\n\n## Design Principles\n\n- **Performance**: Must match or beat lodash.\n- **Simplicity**: Simplest interface for the 85% use case. No complex options.\n- **Don't implement**: Functions replaceable by modern JS (`Array.isArray`, `Number.isNaN`, `Math.min`), or TC39 Stage 3+ proposals.\n- **es-toolkit vs compat**: `es-toolkit` is the strict, opinionated API. `es-toolkit/compat` matches lodash behavior exactly for migration. Compat is feature-complete — no new functions are being added. Only behavior inconsistency fixes against lodash are accepted.\n- **What we accept**: New functions need an accepted [discussion](https://github.com/toss/es-toolkit/discussions/new?category=ideas) first, performance work needs benchmark results, and refactoring-only changes are not accepted. See [`.github/CONTRIBUTING.md`](./.github/CONTRIBUTING.md#41-what-we-accept).\n\n## Coding Conventions\n\n- `for` loops over `reduce` (local mutation is fine)\n- Built-in JS over custom helpers (`Array.isArray()`, not `isArray()`)\n- Type params: `T` elements, `K` keys, `E` errors\n- `readonly T[]` for array params that aren't mutated\n- Detailed JSDoc with `@template`, `@param`, `@returns`, `@throws`, `@example`\n\n## New Function Checklist\n\n1. `src/{category}/{fn}.ts` — Implementation\n2. `src/{category}/{fn}.spec.ts` — Tests\n3. Re-export in `src/{category}/index.ts` and `src/index.ts`\n4. Docs in all 4 languages (see `docs/CLAUDE.md` for templates)\n","category":"root","tokens":635}]}