build: configure static globals to control bundle/debug code #4273
Conversation
mitsuhiko
force-pushed
the
feature/globals
branch
from
14c2654 to
f8c7f26
Compare
size-limit report
|
|
This Iooks good - I do think there are ways to optimize it in the future (particularly, it would be nice to find a way to do this which helps slim down not only CDN bundles but also the vendor bundles of folks using us through npm), but I think this is a great start, and should let us start doing the work of sorting code into browser-only, node-only, and shared. I wonder if you might add an example to the description of how this would get used. Would we be putting conditionals around dynamic imports? Or is the idea just that any code that we call inside such a conditional would be dropped because terser would know it would never run? |
|
I'm quite convinced that longer term we want to use something like a global |
Temporarily stop removing debug functionality from the CDN bundle while we work on a more fleshed out bundling solution. We previously added static globals in #4273 to leverage dead code elimination to remove debug functionality from the browser CDN. Currently though, we only publish a single CDN bundle, the one that has the debug functionality stripped. Until we publish seperate CDN bundles for debug and production, we will disable stripped debug functionality from the production bundle.
Temporarily stop removing debug functionality from the CDN bundle while we work on a more fleshed out bundling solution. We previously added static globals in #4273 to leverage dead code elimination to remove debug functionality from the browser CDN. Currently though, we only publish a single CDN bundle, the one that has the debug functionality stripped. Until we publish seperate CDN bundles for debug and production, we will disable stripped debug functionality from the production bundle.
|
apollographql/apollo-client#9386 should fix the original declaration conflict |
|
Perhaps we should switch to using DEV then |
This adds experimental configuration to rollup and terser to make enable dead code elimination for browser bundles. In particular right now we want to make sure some code that is absolutely pointless in browser never makes it there without having to modify reusable code from the node version.
In addition this provides a flag we can then use to turn on/off functionality that's only relevant for debugging.
I was unable to make this work with a constant instead of a function call due to limitations in terser. However this overhead this adds to non terser builds should be small enough that I believe we should be merging this as such and then optimize later to get rid of this newfound overhead.