5 ms·

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

by korijn 4y ago

afavour 4y ago
[delete]
- jwolfe 4y ago
  You're misreading that source. It's the separate npm packages that are deprecated, not the module imports.
  - deleted 4y ago
    [deleted]
- toastercat 4y ago
  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`).
- deleted 4y ago
  [deleted]
toastercat 4y ago
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.
- joshmanders 4y ago
  > 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.
88913527 4y ago
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.
- BurningFrog 4y ago
  I would look at making a test/checker that fails the build for such imports. With that approach fallible humans carry less risk.
- korijn 4y ago
  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.
  - jacobr 4y ago
    Because it’s easier to just not use lodash.

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

by korijn 4y ago

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

afavour 4y ago

[delete]

jwolfe 4y ago
You're misreading that source. It's the separate npm packages that are deprecated, not the module imports.
- deleted 4y ago
  [deleted]
toastercat 4y ago
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`).
deleted 4y ago
[deleted]

toastercat 4y ago

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.

joshmanders 4y ago
> 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.

88913527 4y ago

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.

BurningFrog 4y ago
I would look at making a test/checker that fails the build for such imports. With that approach fallible humans carry less risk.
korijn 4y ago
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.
- jacobr 4y ago
  Because it’s easier to just not use lodash.