Use native or/and lodash modules instead of the whole lodash lib #291
Conversation
|
Thanks for the PR! I'll need to fix the travis builds first (#292) before we can merge this, please give me a bit of time to get that sorted and I'll come back to review this. |
|
Sure! Thank you. :) |
|
@kud I think it's fixed now. Can you push a new empty commit to this branch to kick off a build? |
There was a problem hiding this comment.
As part of this PR would you be able to share bundle sizes you observe before and after these changes? I guess I was under the impression when we wrote this library that babel would automatically treeshake unused parts of lodash out of the bundle. I wonder if I was wrong about that or if something's changed with tooling over the years.
.prettierignore
Outdated
| @@ -0,0 +1 @@ | |||
| * | |||
There was a problem hiding this comment.
I assume this is to prevent your editor from autoformatting? It would be nice to introduce prettier to this project in a future PR, but for now can you remove this file?
Hello @danpaz . I understand your questionning/thoughts. The thing is it's great from you to have added the lodash babel plugin to reduce the size of the build via a tree shaking. However, it doesn't work for the final user of your lib if they don't add this optimisation. It works for your final built but not if the user imports your lib via commonjs/esm, which is my case. That's why I'd like via this PR to suggest using only what it matters. For the result, I saw that webpack-bundle-analyzer doesn't display anymore lodash in my final built. Which is great. :) |
|
Thanks 😊 |
I wanted to reduce the impact of this lib on my application, as it uses lodash in global and it is a bit huge.
For that I use either what was said here https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore or some lodash modules to be sure to have the same result.
This is a first shot. Maybe we can go deeper one day by removing all lodash modules but this is already a first step.