Version 2.0.2 with lodash-es added 7kB to the bundle size

[albertogasparin]

I read that the reason to switch to lodash-es was that few other libs use this version. However, let me highlight that for people like me that use lodash (as the majority of Lodash users based on npm stats) this change increased the build size by 7kB (minified).
Moreover, looks like babel-plugin-lodash and lodash-webpack-plugin have no effect on lodash-es.
As lodash@5 will probably make lodash-es deprecated (as it will be like it out of the box) is this change really worth it?

[yangmillstheory]

@jaridmargolin can you respond?

[yangmillstheory]

@albertogasparin I should have researched this further. If you could post some convincing statistics, I'd be happy to revert. In general, it would be great to have more active participation in PRs (anyone can comment I believe), since front-end is less of a focus for me these days.

[jaridmargolin]

@yangmillstheory - this is absolutely a beneficial technique accepted by the community.

redux, redux-react, redux-persist, etc (there are more) all use this technique, and being able to share methods with them WILL reduce package size. Some back story on the issue can be found here: reduxjs/redux#1369

@albertogasparin - Sorry that the change has temporarily increased your bundle size. Implementing lodash-es within your project may be beneficial as it is already in use by the libraries mentioned above (one of them being a direct dependency). There is no reason to include lodash and lodash-es methods.

* If you do not want to change files manually, perhaps you could implement the same shim the libraries do https://github.com/reactjs/redux/blob/master/build/use-lodash-es.js ?

As lodash@5 will probably make lodash-es deprecated (as it will be like it out of the box) is this change really worth it?

This seems like a problem we can deal with when lodash@5 comes out.

[albertogasparin]

I don't know about all other libs, but both redux and react-redux are using a single lodash method (isPlainObject). For people not using lodash at all, the es-version is smaller than the standard one and for people using it the additional cost is ~500B, so negligible.

redux-actions on the over side uses several lodash methods, so the amount of duplicated code jumps to nearly 7kB (worst scenario). I don't have specific stats about people using redux-actions + lodash vs redux-actions + lodash-es, but @jaridmargolin let me disagree with your "absolutely beneficial" statement.

Anyway, I've opened the issue just to be sure that you guys are conscious of the effects of #206. On my end I've solved the duplication problem with Webpack:

new webpack.NormalModuleReplacementPlugin(
  /^lodash-es(\/|$)/, (res) => {
    res.request = res.request.replace(/^lodash-es(\/|$)/, 'lodash$1');
  }
)

So I leave it here just in case someone else looks for a solution.

[jaridmargolin]

@albertogasparin I do appreciate your perspective andI think it is great to have a track record for anyone else who bumps up against this. I saw around a 6KB reduction in my case. This solution provides the opportunity for people utilizing additional libraries to notably cut down on unnecessary bloat.

I am by no means the MOST qualified to speak on the pros/cons of the technique. @jdalton - Do you have any insight into the implications of using lodash vs lodash-es?

[jdalton]

if the versions of both lodash and lodash-es are ^4 then you should be fine as the lodash-es package is just the lodash one with import/exports. I know @TheLarkInn has done some work to consolidate lodash and lodash-es and other packages into a single set.