Optimize lodash imports by using babel-plugin-lodash#100
Conversation
17c1ce7 to
954861d
Compare
|
What for? – it is a server-side library. |
|
I'm currently importing this into an aws lambda with webpack (tree shaking ftw!) and without this change, my build goes up by 500k. |
and what difference does 500k make in the context of lambda? |
|
lambda start time, node start time, memory usage, it's not insignificant. With lambdas you pay for time and memory, so something like this does make a difference if you're doing hundreds of thousands of lambda executions |
How much does this impact lambda start time, node start time or memory usage? |
|
Is there a reason you don't want to include this transform? |
|
I will happily include the change if you demonstrate that there is any measurable benefit to it. Otherwise, it is just an unnecessary abstraction that will confuse future maintainers of the package. As it is, the request and the problem that you describe does not make much sense to me. I don't see why 500kB or even 1MB would affect script execution time or node start time. Even if it was a whooping 100MB difference – I struggle to see how would that impact measurably any of the things that you've described. But I am not rushing to say this because perhaps I am not familiar enough with how Lambda works and you have experience that taught you otherwise. Therefore, I think I am asking a fair question: How much does this impact lambda start time, node start time or memory usage? |
|
For what it is worth, this articles states that bundle size has no effect. Again, perhaps I am and the author of the article are not familiar enough with how Lambda works and you have experience that taught you otherwise. If you share evidence that demonstrate otherwise, I will happily merge this change. |
|
It really falls under the philosophy of death by a thousand cuts. While one library of 500k might not move the needle a lot, if you have a dozen of those, it starts to add up. Importing the whole lodash library increases the node memory footprint by 3.6 megs give or take and increases the start time of node by 50ms on my machine (though start times vary by machine). Checking out https://aws.amazon.com/lambda/pricing/ you can get a rough estimate of how much it costs per 100ms, then multiplied by hundreds of thousands of requests. So there is a cost savings when you scale up. |
|
An alternative to the plugin is just changing all lodash references by hand and then adding this eslint plugin to guard against people importing the whole library https://github.com/wix/eslint-plugin-lodash/blob/master/docs/rules/import-scope.md But I figured the babel plugin was less intrusive |
|
🎉 This PR is included in version 5.4.5 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This PR optimizes the dist output by adding babel-plugin-lodash which rewrites lodash imports to only import the specific functions used.
Example:
becomes
This allows tools like webpack and rollup to tree-shake this library better without importing the whole lodash js file