Skip to main content

Deprecate use of lodash over time

We are currently using the utility library lodash throughout the frontend codebase. However, many of the methods provided by lodash have been superseded by native ES6+ methods. Even the latest ECMAScript functionality that is not natively supported by our target browsers (such as IE11) will be transpiled and/or polyfilled with our existing Webpack & Babel configuration. Continuing to use lodash methods as-is has two negative effects:

  • Inconsistent usage as some contributors will opt to use native JS functions instead of the lodash alternative
  • An additional 3rd party dependency that we need to keep updated, and adds to our bundle size

I am proposing that we fully deprecate usage of lodash methods that have native JavaScript equivalents. We can use the You Don’t Need Lodash/Underscore ESLint plugin to begin enforcing consistent usage on a per-method basis. Additionally, we can use the lodash-webpack-plugin and babel-plugin-lodash to cherry-pick lodash methods with no native equivalent that we may want to continue using (such as uniqueId), and result in a smaller bundle.

Additionally, this strategy leaves us open to completely removing lodash as a dependency in the future if we so choose. I'm focusing on bundle size over individual method benchmarks, because it is well-documented that reducing parse & compile time is the most effective way to improve performance on mobile devices.

Note that some of the native equivalents are not exactly the same as the lodash versions. The links below point to documentation for any differences.

Methods to deprecate (links to eslint plugin docs):

Methods to retain (links to lodash docs):

Considered Alternatives​

  • Deprecate lodash methods that have close native equivalents
  • Deprecate lodash entirely
  • Switch from native methods to only lodash methods
  • Don't change lodash usage, but add Babel & Webpack plugins
  • Do nothing

Decision Outcome​

  • Chosen Alternative: Deprecate lodash methods that have close native equivalents.
  • Additionally, set up the lodash-webpack-plugin and babel-plugin-lodash to optimize how lodash adds to our bundle size.
  • + Enforce one consistent style throughout the codebase
  • + Can replace existing lodash methods on a per-method basis using the ESLint plugin (and prevent more instances from being added)
  • + Lodash imports will be optimized and should reduce bundle size
  • - Need to socialize and educate engineers on the native methods to use instead

Pros and Cons of the Alternatives​

Deprecate lodash entirely​

  • + Removes a significant library dependency
  • + Enforce one consistent style throughout the codebase
  • - Would have to immediately replace existing lodash methods throughout the code
  • - Need to find alternate solutions for lodash methods that have no native equivalent (such as uniqueId)

Switch from native methods to only lodash methods​

  • + Enforce one consistent style throughout the codebase
  • - Increased reliance on a third-party library, and learning curve for engineers who are more familiar with native JS than with lodash
  • - Our code is further removed from native JS implementations and future proposals

Don't change lodash usage, but add Babel & Webpack plugins​

  • + Requires no code or habit changes (other than Webpack/Babel config)
  • + Lodash imports will be optimized and should reduce bundle size
  • - Perpetuates inconsistent code styles and confusion for new engineers

Do nothing​

  • + Requires no immediate effort
  • - Perpetuates inconsistent code styles and confusion for new engineers
  • - Lodash continues to account for ~98KB of our bundled frontend assets