developit / microbundle

📦 Zero-configuration bundler for tiny modules.
https://npm.im/microbundle
MIT License
8.04k stars 362 forks source link

Should babelHelpers be `runtime` ? #893

Open nolde opened 3 years ago

nolde commented 3 years ago

In rollup's documentation, there the following excerpt:

'runtime' - you should use this especially when building libraries with Rollup. It has to be used in combination with @babel/plugin-transform-runtime and you should also specify @babel/runtime as dependency of your package. Don't forget to tell Rollup to treat the helpers imported from within the @babel/runtime module as external dependencies when bundling for cjs & es formats. This can be accomplished via regex (external: [/@babel\/runtime/]) or a function (external: id => id.includes('@babel/runtime')). It's important to not only specify external: ['@babel/runtime'] since the helpers are imported from nested paths (e.g @babel/runtime/helpers/get) and Rollup will only exclude modules that match strings exactly.

I've noticed microbundle uses bundled option... is there any way to change/configure this? And should microbundle use runtime by default, given that it focuses in library bundling?

developit commented 3 years ago

This might be slightly on the side of personal preference, but here's my reason for not using runtime: when building small libraries for the browser, importing a single tiny function from a 5mb dependency that can't be tree-shaken is not a good default. In general, Microbundle's Babel configuration avoids pulling in helpers wherever possible - this only tends to be an issue when Babel is reconfigured in more verbose (non-loose/strict) modes, which Microbundle isn't really designed for.

jacobrask commented 2 years ago

I'm sure I'm missing something with the tree-shaking, but when I've used babel runtime it outputs imports like import _extends from "@babel/runtime/helpers/extends"; - can't that be tree-shaken and bundled quite nicely?