From es-toolkit
Migrates Lodash code to es-toolkit by replacing imports, reducing bundle size, and comparing strict vs compat APIs from source code.
npx claudepluginhub toss/es-toolkit --plugin es-toolkitThis skill is limited to using the following tools:
Guide users through migrating lodash to es-toolkit and understanding the strict vs compat APIs, grounded in actual source code.
Recommends es-toolkit utility functions matching user requirements or code by searching source/docs, with imports, examples, doc links, and comparisons.
Generates jscodeshift or ts-morph codemods for design system migrations: token renames, component API changes, prop deprecations, import updates.
Evaluates dependencies before npm/pip install: assesses bundle size, tree-shaking, maintenance, vulnerabilities, docs, alternatives, and recommends add, reject, or implement internally.
Share bugs, ideas, or general feedback.
Guide users through migrating lodash to es-toolkit and understanding the strict vs compat APIs, grounded in actual source code.
$ARGUMENTS — Lodash code to migrate, specific function names, or a question about strict vs compat.
es-toolkit (strict): Opinionated, simplified API for the 85% use case. Smaller bundle, may differ from lodash in edge cases by design. New functions are added here.
es-toolkit/compat: Aims for full lodash test compatibility within a defined scope. See docs/compatibility.md for out-of-scope behaviors (e.g., implicit type conversions, prototype modifications).
The only reliable way to know the difference between strict and compat is to read the actual implementation. Never guess — always verify from source.
Extract which lodash functions are used and how they're imported.
For each function, search both APIs:
src/{category}/{fn}.ts — strict APIsrc/compat/{category}/{fn}.ts — compat APIRead the implementation to understand the exact signature and any behavioral differences.
| Scenario | Recommendation |
|---|---|
| Function exists in both, same behavior | Use es-toolkit (smaller bundle) |
| Function exists in both, different behavior | Explain the difference, let user choose |
| Only in compat | Use es-toolkit/compat |
| Not available at all | Keep lodash or suggest modern JS alternative |
If the function only exists in compat (like get, set, has), explain why — es-toolkit doesn't implement functions replaceable by modern JS (optional chaining ?., Object.hasOwn(), etc.).
For each function, provide:
https://es-toolkit.dev/reference/{category}/{fn} (strict) or https://es-toolkit.dev/reference/compat/{category}/{fn} (compat)| Feature | lodash | es-toolkit | es-toolkit/compat |
|---|---|---|---|
| (list each option/capability) | ✅/❌ | ✅/❌ | ✅/❌ |
For migrations involving many functions, use a summary table instead of repeating the full template for each one.
Show the final import transformation as a single block.
When migrating many files, mention practical automation approaches:
resolve.alias in webpack or Vite to redirect lodash imports at build time without changing source files:
// vite.config.js or webpack.config.js
resolve: { alias: { 'lodash': 'es-toolkit/compat' } }
no-restricted-imports to warn or error on remaining lodash imports after migration.es-toolkit is up to 97% smaller than lodash and 2-3x faster. Bundle size numbers come from benchmarks/bundle-size/ and runtime performance numbers from benchmarks/performance/ and docs/performance.md — reference them for specific function comparisons if the user asks.
Provide a strategic overview with three migration options:
For each option, include a trade-off matrix:
| Factor | Option A (strict) | Option B (compat) | Option C (mixed) |
|---|---|---|---|
| Code change volume | High | Low | Medium |
| Bundle size reduction | Maximum | Moderate | Varies |
| Risk level | Higher (behavior diffs) | Low (lodash-compatible) | Medium |
| Maintenance effort | Low (clean API) | Medium (compat tracking) | Higher (two APIs) |
Compat-exclusive functions: Search src/compat/ for functions that don't exist in src/ (strict). List representative examples so users know what can only come from compat (e.g., get, set, has).
For concrete behavioral differences, read a few representative function pairs from source (e.g., chunk, debounce) to give real examples rather than abstract descriptions.
If you need to check whether a lodash function has an es-toolkit equivalent:
docs/reference/{category}/{functionName}.md directlyGrep for the function name across docs/reference/**/*.mdGlob docs/reference/compat/{category}/*.md — then check if the same file exists in docs/reference/{category}/