3 ms·
This is a neat summary of how they shaved some source and developer time! A trick I've used to shave bundle sizes: re-mapping `babel-runtime/*` to `@babe/runti
by no_wizard 4y ago
This is a neat summary of how they shaved some source and developer time!
A trick I've used to shave bundle sizes: re-mapping `babel-runtime/*` to `@babe/runtime` and proper core-js imports and `core-js` imports from V2 to V3 latest imports ones. This shaved tons off of my bundles (unfortunately have some libraries we rely on that are both substantial but old)
Another one is library deduping. I've re-mapped all of the `lodash.*` to be direct default imports, e.g. `lodash.merge` to `lodash/merge`. Also shaved a ton off my bundle sizes.
- gandreani 4y agoDid you do the re-mapping using webpack? I haven't heard of this approach before and it sounds really promising
- no_wizard 4y agoI did! Was pretty painless, just followed their documentation on configuring resolve settings
- lhnz 4y agoDoesn't this risk the possibility that a new version of these libraries either behaves slightly differently or has different public exports?
- no_wizard 4y agoTests can cover this really well. I also find that lodash and Babel runtime packages were extremely stable APIs. If an API changes a lot it’s not the best strategy. You have to know your dependency chain
- lobo_tuerto 4y agoWouldn't lodash-es and tree-shaking take care of that?