Bundle umd with rollup #681
Conversation
|
Any update on this? |
|
Sorry, I've been sidetracked. I'll be looking into this soon! |
| "rollup": { | ||
| "plugins": [ | ||
| "./build/use-lodash-es", | ||
| "external-helpers" |
There was a problem hiding this comment.
So, do we have to externalize Babel's helpers? This introduces a rather opaque dependency, since it's not explicitly listed in package.json or anything. What if we use transform-runtime instead to centralize helpers within the build? Does that bloat things a lot?
There was a problem hiding this comment.
And then tree shaking removes unnecessary helpers.
There was a problem hiding this comment.
Sorry, confused by github reviews.
rollup-plugin-babel calls buildExternalHelpers, adds it as virtual module and then tree shake unnecessary code. So all in the same bundle, not external package
There was a problem hiding this comment.
Well, transform-runtime should only add used helpers by itself. But there can be a tree of helpers using other helpers underneath that. I would just ensure the { polyfills: false } option is used so it doesn't try to polyfill everything. That can be left up to the user.
There was a problem hiding this comment.
It doesn't try to polyfill everything. Used is only what added by plugins in .babelrc. And it looks like runtime plugin adds core-js stuff under the hood. And it's common js afaik.
There was a problem hiding this comment.
Sure, but I don't know how to best advertise to UMD users that they need this thing that isn't in the dependency list. It seems really error-prone.
I'll do some checking into this when I have a chance later tonight. I'm sure this stuff can be inlined without causing a ton of bloat. It's a babel issue, not webpack or rollup's job.
There was a problem hiding this comment.
Why do you want one more dependency for umd users? Now helpers are builtin with umd bundle. You want to make life harder?
There was a problem hiding this comment.
No, I'm saying don't make them external. If you do, that becomes a dependency. transform-runtime inlines and centralizes helpers, so they don't need to be imported by the user, but are still efficient because there is only ever one copy of a helper.
There was a problem hiding this comment.
Yeah, and that what rollup-plugin-babel do. External plugin just add namespace to helpers which is used by rollup-plugin-babel. But that happen without additional and not always efficient work by commonjs plugin and expliit dependency which developer should specify instead of what exactly plugins require.
There was a problem hiding this comment.
OK, I apparently have a fundamental misunderstanding of babel-plugin-external-helpers or rollup-plugin-babel does :P
external-helpers is supposed to tell the transpiled code to look at global for the babelHelpers property to find them. That means they should be external (like the name implies) from the build and included via a separate <script> tag. For whatever reason, rollup-plugin-babel actually treats them like an inline-able dependency, which is what transform-runtime is supposed to do.
Anyways, that's just my 2 cents. Since the naming is backwards, this is actually what we want and I was wrong about it originally :)
|
OK, this builds A-OK, so we're good to go. Here's what the output looks like for the curious: https://gist.github.com/timdorr/997620e0980f53087fdbef36d6a6f750#file-react-redux-js |
82 798 -> 65 835
19 181 -> 12 773
Ref #680