-
Notifications
You must be signed in to change notification settings - Fork 47.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Move Everything to ES Modules in Builds #18094
Conversation
We shouldn't need this and we accidentally rely on it just by it existing.
These were conditionally trying to export the default before but they never actually exported a default. Same things with react-refresh. For Debug Tools I stuck with exporting default for now. This will now cause Rollup to mutate the exports object so I changed the wrappers. I don't know why the wrappers can't just use shadowing but I changed it to use shadowing so we don't have to use the mutation hack.
This will have esModule compatibility flag on them. They should ideally export default instead.
This one uses ES modules so that we can inline it into UMD builds.
…odules This shouldn't change and is really mostly barely supported. It's better to control this if we're going to inline it anyway.
…dency not inlined It uses spread or Object.assign in a single place which takes on this dep. :(
@@ -0,0 +1,97 @@ | |||
/* | |||
object-assign |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
} | ||
}; | ||
|
||
export default checkPropTypes; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
@@ -9,6 +9,28 @@ | |||
|
|||
'use strict'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe remove use strict everywhere?
Done in other PRs. |
It turns out that our loose reliance on CommonJS isn't really letting Rollup do its best work. It's also covering up a bunch of quirks that cause other issues and this ends up leaking. We really only intended it to be used to suck in requires into UMD builds. Unfortunately it also means that we're actually inlining in a bunch of builds accidentally too.
The usage of CommonJS at the export level also covers up a bunch of issues by converting it first into an intermediate layer of CommonJS and then back again.
I want to get to a point where we can remove the CommonJS plugin from Rollup. I was hoping we could just fork the object-assign and prop-types ones because 1) both of these are kind of frozen and we should ideally get rid of the dep in the next version 2) umds are likely to get dropped soon too anyway. Unfortunately react-art also supports UMD, for some reason, and it's harder to fork all of art. I might end up keeping the CommonJS plugin but only for ART for this reason until we can kill those UMD bundles.
We should also start preparing for actually exporting ES modules. Right now we're not very rigid with how we export things. We should be always exporting a default for now since that gives us the best CommonJS output. We can't start exporting the esModule flag since that would start breaking things.
(Although I settled on just doing that for react-interactions because it was easier and it's FB only.)
However, this means that importing named imports etc. don't work. Including in our own code. Like DevTools. So we'll need to fix that up too.
There's a bunch to do here and I'm really just getting started.