Html-webpack-plugin: lodash as a dependency ./~/html-webpack-plugin/~/lodash/lodash.js

[t0lkman]

is it possible not to include lodash?
How do I configure the plugin not to use lodash?

[mastilver]

What is your argument against lodash?

You can use another loader, by following: https://github.com/jantimon/html-webpack-plugin/blob/master/docs/template-option.md

[iamolivinius]

For me it's no argument pro or against lodash. It just seems like the plugin is the reason why lodash is bundled into my "bundle.js"

[mastilver]

@iamolivinius Did you try using another loader?

[t0lkman]

btw by default lodash is used but is it only in dev mode bundled into the bundle.js or also in the production?
I really don't care if it's inside the bundle while developing, but I don't want to see it in the production if I don't use any of its features...

[jantimon]

If lodash get's bundled into your package that would be either a bug or a miss configured webpack config.

Webpack can bundle several entries into separated bundles. The html-webpack plugin creates one seperate bundle.

[iamolivinius]

Some deeper analysis of our bundle showed that we had a dependency that relies on lodash. Usually we use lodash-es only so I got a little bit confused when I read the output of this plugin.

From my side: sorry for stirring up the dust! It's all fine 😸

[ozankasikci]

I don't even have lodash in my package json but htm-webpack-plugin still includes it into production bundle?

[jacobdam]

I don't have any argument against lodash. But for me, loading the whole lodash object is unnecessary. I think load specific lodash methods is better than loading the whole lodash object:

// This one
var _template = require('lodash/template');
var _defaults = require('lodash/defaults');
_template(source, _defaults(...));

// is better than this one
var _ = require('lodash');
_.template(source, _.defaults(...));

[jantimon]

@jacobdam thanks this probably the best way to use lodash - but where is the measurable advantage in nodejs over using just the entire lodash library?

[jacobdam]

I noticed that after adding this plugin to my project, the command webpack displays ~100 lodash modules which I don't use. I don't have any evident that use lodash method style is better than lodash object style. But it seems the lodash method style is used in some popular repo (such as babel, eslint, enzyme, etc).

Btw, From lodash's README, https://github.com/lodash/lodash/#installation.

// Cherry-pick methods for smaller browserify/rollup/webpack bundles.
var at = require('lodash/at');
var curryN = require('lodash/fp/curryN');

[jacobdam]

I know that ~100 lodash modules are not emitted into my main bundle. So the lodash method style is just a little bit better than import lodash object style. And in my case, it can help me to debug what in my main bundle easier.

[jacobdam]

webpack displays ~100 lodash modules

I lied about this. babel warning me about code generator has deoptimised module lodash/lodash.js > 500kB. I thought lodash added 100 modules.

[bugeats]

Uhh, I'm building with webpack -p with a basic HtmlWebpackPlugin (^2.30.1) config and it's definitely including lodash in the bundle output -- which adds like 500k. I've analyzed my dep tree with both npm and webpack, and HtmlWebpackPlugin is the only thing that is requiring lodash.

[mastilver]

@bugeats Can you provide us with a repository to reproduce?

[bugeats]

@mastilver I'm working on a private repo. I'm not opposed to spinning up a repo to repro, but let's try a few other things first.

I was able to eliminate lodash from my build by adding this exclude key to my js loader config:

{
    test: /\.(js|jsx)$/,
    loader: 'babel-loader',
    exclude: path.resolve('node_modules/lodash')
}

I get that most people are excluding node_modules/* from their builds, and so omitting this common config could be considered user error. However, I still don't understand why adding an HtmlWebpackPlugin instance to the webpack plugins would including it's private dependencies in my bundle.

[mastilver]

However, I still don't understand why adding an HtmlWebpackPlugin instance to the webpack plugins would including it's private dependencies in my bundle.

Me neither, that's why a simple repo to reproduce it will move things faster (I'm not experiencing this issue but it still concern me). There is a good change it's not due to HtmlWebpackPlugin but I would prefer be sure and maybe help you figure out the issue

[bugeats]

Derp. I may have been wrong. I can no longer repo lodash in my bundle during webpack -p. Of course, it IS still in there with webpack, but I understand that's expected.

[mxstbr]

I'm also running into this, the stats object shows that htmlwebpackplugin is bundling all of lodash into my browser bundle?!

[mxstbr]

Unfortunately exclude: path.resolve('node_module/lodash') doesn't work for me :cry:

[jantimon]

I don't know how well the stats plugin will display the correct results for child compilers.

@mxstbr how could exclude help with that? can you try to find out in your generated js bundle file which script is loading lodash?

[mxstbr]

@jantimon dunno, just tried @bugeats suggestion 🤷‍♂️

The thing is, none of them are 😅 HTMLWebpackPlugin is the only thing

[jantimon]

Any special common chunks configuration?

[mxstbr]

Only whatever create-react-app ships with and

  config.plugins.push(
    new webpack.optimize.CommonsChunkPlugin({
      names: ['bootstrap'],
      filename: './static/js/[name].js',
      minChunks: Infinity,
    })
  );

To get a bundle that only has the webpack bootstrapping code.

[jantimon]

Well this bug didn't happen for older webpack version - maybe @sokra has an idea what changed

[DanielSchaffer]

I just ran into this. From what I understand, html-webpack-plugin uses lodash templates by default, which means it has to include lodash as a dependency in order for the templates to be rendered. As an aside, I'm not entirely clear as to why the default functionality is to do it like this rather than statically render the HTML template, no inclusion of dependencies required - but the fix is actually quite easy: Just add a webpack loader for your desired template language. If you're just using a static HTML template, use html-loader:

{
  test: /\.html$/,
  loader: 'html-loader'
}

You can also use PUG, or whatever else. FWIW, this is all covered here: https://github.com/jantimon/html-webpack-plugin/blob/master/docs/template-option.md

[lock[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.