Simulating different approaches for code-splitting lodash.
In index.js, both lodash
& lodash-es
dependencies are used for simulating code-splitting with different webpack configurations.
Four webpack configurations are used to see which config approach yields the best results. Each configuration is also accompanied by a webpack-bundle-analyzer
-report which can be found in the dist-folder.
These are the 4 configurations:
- non optimized
- lodash babel plugin
- lodash webpack plugin
- combination of babel and webpack plugins
Only entry & output properties are used in non-optimized config.
Only babel-plugin-lodash
is used in this config with babel plugin.
Only lodash-webpack-plugin
is used in this config with webpack plugin.
A combination of babel-plugin-lodash
and lodash-webpack-plugin
is used in this config with babel and webpack plugins.
Config | File | Size |
---|---|---|
babel and webpack plugin | dist/babel-webpack.js | 1.96 KB |
babel plugin | dist/babel.js | 21.90 KB |
webpack plugin | dist/webpack.js | 71.50 KB |
non optimized | dist/non-optimized.js | 79.60 KB |
The configuration where both babel and webpack plugins are used, result in a staggering small bundle size. The reason why is because a lot of behind-the-scene features of lodash are removed by the lodash-webpack-plugin
, which explains the big savings.
For example, lodash's get
will not behave as expected if lodash-webpack-plugin
is used.
Here's a full list of features that are disabled by lodash-webpack-plugin
:
github.com/lodash/lodash-webpack-plugin#feature-sets.
You can choose to opt-in to certain features like this:
new LodashModuleReplacementPlugin({
collections: true,
paths: true
});