Open jedwards1211 opened 5 years ago
Here's a demonstration of this. Since throttle
uses debounce
internally, importing lodash/throttle
and lodash/debounce
is able to share the debounce
code and make a smaller bundle. But if you import lodash.throttle
and lodash.debounce
, the debounce
code is duplicated internally in lodash.throttle
, making a bigger bundle.
lodash-submodules.js
import throttle from 'lodash/throttle'
import debounce from 'lodash/debounce'
webpack lodash-submodules.js
sset Size Chunks Chunk Names
main.js 3.79 KiB 0 [emitted] main
Entrypoint main = main.js
[4] ./lodash-submodules.js 78 bytes {0} [built]
[8] (webpack)/buildin/global.js 472 bytes {0} [built]
+ 13 hidden modules
lodash-per-method-packages.js
import throttle from 'lodash.throttle'
import debounce from 'lodash.debounce'
webpack lodash-per-method-packages.js
Asset Size Chunks Chunk Names
main.js 4.55 KiB 0 [emitted] main
Entrypoint main = main.js
[0] (webpack)/buildin/global.js 472 bytes {0} [built]
[1] ./lodash-per-method-packages.js 78 bytes {0} [built]
+ 2 hidden modules
thanks for the info
See https://github.com/lodash/lodash/issues/3838
If two lodash per-method packages, e.g.
lodash.throttle
andlodash.debounce
, depend on an underlying lodash function (public or internal API), that function will be inlined in each of the modular build packages, bloating webpack bundle size. The modular build packages can't share any code.On the other hand, if your package imports from
lodash/throttle
, and another package imports fromlodash/debounce
, they can share any underlying code they depend on and the webpack bundle will be smaller.So the per-method packages really have no advantages, and John-David Dalton pointed out that they're going to be removed in v5.
Having
lodash
as a dependency is perfectly fine as long as you always import from submodules, never its root module.