Optimize Lodash imports to reduce bundle size

[enagorny]

Description

This PR proposes to optimize Formik's use of Lodash by replacing the full Lodash library with individual method imports. This change aims to reduce the overall bundle size of projects using Formik by only including the specific Lodash methods that Formik requires.

Changes

• Remove dependencies on full lodash and lodash-es packages
• Add individual Lodash method packages: lodash.clone, lodash.clonedeep, lodash.isplainobject, lodash.topath
• Update corresponding TypeScript type definitions
• Modify import statements in the codebase to use the individual method packages

Motivation

The full Lodash library is quite large, and Formik only uses a few methods from it. By importing only the necessary methods, we can significantly reduce the amount of unused code included in the final bundle.

Potential Impact

• Reduced bundle size for projects using Formik
• Potentially faster load times for applications
• No change in functionality or API

Testing

(Describe any testing you've done here. For example:)

• Ran the existing test suite to ensure no regressions
• Manually tested key Formik functionalities
• Compared bundle sizes before and after the change (provide metrics if available)

Notes for Reviewers

• Please check if there are any Lodash methods I might have missed
• Confirm if this aligns with the project's dependency management strategy
• Suggestions for additional testing or benchmarking are welcome

[changeset-bot]

🦋 Changeset detected

Latest commit: 5f49e03

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
formik	Patch
formik-native	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
formik-docs	⬜️ Ignored (Inspect)	Visit Preview		Aug 6, 2024 0:26am

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[FezVrasta]

Seeing a before and after comparison of the library size would be helpful.

[quantizor]

I found this which might be useful https://www.npmjs.com/package/@optimize-lodash/rollup-plugin

As for whether lodash.* or lodash/* is better, I think it mostly depends on how the lodash library is packaged. If it's importing from lodash.* internally then it won't duplicate the code for a downstream consumer, but if lodash.* are separately-built extractions then I think bundlers would keep both copies if they're in the same project leading to a bit of bloat.

Long story short, I'd say let's do deep imports or consider using that rollup plugin with tsdx.

[simonbuchan]

lodash-es was supposed to fix this, but apparently it mostly depended on webpack magic? Regardless, you definitely shouldn't need both lodash and lodash-es

Since it's quite dead now at this point anyway you should be migrating to es-toolkit instead: https://es-toolkit.dev/