refactor: migrate from lodash to es-toolkit

[vtaits]

Hello. It's a suggestion to migrate from lodash to es-toolkit.

The main advantages are: it's smaller, faster, more es-friendly and ts-friendly and popular enough.

https://github.com/toss/es-toolkit

Summary by Sourcery

Replace lodash usage across the codebase with es-toolkit utilities and update dependencies accordingly.

Enhancements:

• Refactor components, hooks, and HOCs to use es-toolkit helpers instead of lodash for common operations.
• Update list, table, pagination, layout, and legacy UI utilities to align with es-toolkit APIs while preserving behavior.

Build:

• Swap lodash for es-toolkit in runtime dependencies and remove @types/lodash from development dependencies in package.json.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Replaces lodash with es-toolkit across the project, updating dependencies and refactoring all lodash-based utilities, hooks, and components to use es-toolkit APIs instead, while keeping existing behavior intact.

File-Level Changes

Change	Details	Files
Replace lodash dependency with es-toolkit and remove lodash type definitions	Swap runtime dependency from lodash to es-toolkit in package.json Remove @types/lodash from devDependencies Regenerate package-lock.json to reflect es-toolkit and lodash removal	package.json package-lock.json
Refactor React components and hooks to use es-toolkit instead of lodash utilities	Update imports from lodash to es-toolkit in shared UI components such as List, Pagination, Select stories, and Table components/stories Replace lodash collection and array helpers (e.g., map, filter, sort, group, uniq, flatten) with equivalent es-toolkit functions while preserving logic Adjust any lodash-specific patterns (like chain or iteratee shorthand) to explicit es-toolkit or native JS implementations	src/components/ActionsPanel/components/hooks/useDropdownActions.ts src/components/Hotkey/parse.ts src/components/List/List.tsx src/components/Pagination/utils.ts src/components/Select/__stories__/Select.stories.tsx src/components/Table/Table.tsx src/components/Table/__stories__/Adaptive.tsx src/components/Table/__stories__/Table.stories.tsx src/components/Table/__stories__/WithTableSettingsCustomActions/WithTableSettingsCustomActions.tsx src/components/Table/hoc/withTableActions/withTableActions.tsx src/components/Table/hoc/withTableCopy/withTableCopy.tsx src/components/Table/hoc/withTableSelection/withTableSelection.tsx src/components/Table/hoc/withTableSorting/withTableSorting.tsx src/components/lab/ColorPicker/ColorPicker.tsx src/components/layout/utils/overrideLayoutTheme.ts src/components/legacy/Breadcrumbs/Breadcrumbs.tsx src/components/useList/hooks/useListFilter.ts
Update shared hooks and utilities that relied on lodash helpers to use es-toolkit or native equivalents	Refactor hooks like useElementSize and useCollapseChildren to replace lodash functions (e.g., debounce, throttle, isEqual, cloneDeep, pick) with es-toolkit counterparts or custom implementations Ensure type-safety and compatibility with existing TypeScript types by aligning es-toolkit function usage with current typings Verify that behavior around memoization, comparison, and structural cloning remains unchanged	src/hooks/private/useElementSize/useElementSize.ts src/hooks/useCollapseChildren/useCollapseChildren.ts

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• Where lodash helpers were used for object/array transformations (e.g., get, set, merge, cloneDeep, isEqual), double-check that the es-toolkit equivalents handle null/undefined, array-like values, and prototype edge cases the same way, or add small adapters where behavior intentionally differs.
• For any lodash utilities that had configurable options (like debounce, throttle, uniqBy, sortBy), verify that the es-toolkit versions match the default options and call signatures you rely on (especially leading/trailing invocation and result memoization), and adjust the call sites to make those assumptions explicit if needed.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Where lodash helpers were used for object/array transformations (e.g., `get`, `set`, `merge`, `cloneDeep`, `isEqual`), double-check that the es-toolkit equivalents handle `null`/`undefined`, array-like values, and prototype edge cases the same way, or add small adapters where behavior intentionally differs.
- For any lodash utilities that had configurable options (like `debounce`, `throttle`, `uniqBy`, `sortBy`), verify that the es-toolkit versions match the default options and call signatures you rely on (especially leading/trailing invocation and result memoization), and adjust the call sites to make those assumptions explicit if needed.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[ogonkov]

Why not lodash-es then?

[gravity-ui]

Preview is ready.

[gravity-ui]

🎭 Component Tests Report is ready.

[amje]

Why not lodash-es then?

I suppose lodash-es has the same flaws as normal lodash: legacy code, bigger size, slower and poor TypeScript support

[ogonkov]

What is a size difference in uikit case between lodash-es and new library?

In our case we already have lodash-es in project, and new library woul be just additional code, that won't be reused

[amje]

What is a size difference in uikit case between lodash-es and new library?

It depends whether or not your other dependencies bring es-toolkit into bundle.

In our case we already have lodash-es in project, and new library woul be just additional code, that won't be reused

So normal lodash is also adds additional code that is not resused. This PR should reduce your bundle size, cuz es-toolkit is much smaller than lodash.

[ogonkov]

We already making our bundle smaller by aliasing lodash to lodash-es in our bundler (this is triggering tree shacking for lodash imports)