Hacker News Reader

Comment by korijn | Hacker News Reader

Importing single modules is so trivial and makes it tree shakeable. Is that really unacceptable?

It's not, but for 3 functions, and reducing our dependencies, it was worth just cutting lodash out. We have been happy with the change.

EDIT: And to be a bit pedantic, importing single modules is not really treeshaking. You're literally just importing and including the entirety of single modules.

> EDIT: And to be a bit pedantic, importing single modules is not really treeshaking. You're literally just importing and including the entirety of single modules.

I'd say that's basically a poor man's treeshaking because you're telling it you only want that module and its dependencies. Not it trying to figure it out for you.

The more practical scalability problem is engineers won't understand the nuance between import from lodash and 'lodash/someFunction'. You then only need one engineer to import 'lodash' and there goes your tree shaking. Front end is a mine field for junior engineers.

All of this crud builds up, and you end up with 25MB bundles and slow SPAs.

I would look at making a test/checker that fails the build for such imports.

With that approach fallible humans carry less risk.

If you're that worried, why not add a CI check on the bundle size as a general smoke detector (useful for more than just lodash) and another check for plain lodash imports with a simple custom eslint rule.

Because it’s easier to just not use lodash.

[delete]

What's being deprecated is the single module packages. So currently, you can do `npm install lodash.merge` and then just use that.

I believe the post you're replying to is referring to what I originally referred to (doing something like `const throttle = require('lodash/throttle')`, which you would install lodash normally for `npm install lodash`).

You're misreading that source. It's the separate npm packages that are deprecated, not the module imports.

Reply on news.ycombinator.com