-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
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
[utils] Use consistent build approach #40837
Conversation
"build:node": "node ../../scripts/build.mjs node --ignoreTopLevel", | ||
"build:stable": "node ../../scripts/build.mjs stable --ignoreTopLevel", |
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.
I should not have added this in #39882
@@ -139,7 +139,7 @@ async function getWebpackEntries() { | |||
...coreComponents, | |||
{ | |||
id: '@material-ui/utils', | |||
path: 'packages/mui-utils/build/esm/index.js', | |||
path: 'packages/mui-utils/build/index.js', |
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.
needs to change to the correct build path since all functions have been moved to subfolders in #39882
Netlify deploy previewhttps://deploy-preview-40837--material-ui.netlify.app/ Bundle size reportDetails of bundle changes (Toolpad) |
It would be nice to get some directional pointers from code-infra, as I read this, the direction we take here might depends on the long-term one mui/mui-x#11016 (comment). |
This is not set in stone. But the rough idea so far was to use v6 to improve ESM compatibility with the exports field*, to unstuck all the issues around loading in vite and Node.js. But keep it largely backwards compatible with bundlers that don't yet understand the exports field. This gives users a full major the opportunity to migrate gradually if necessary. It does however put limits on how much we can change the package layout as many of these setups resolution depends on it. We'd then use v7 or later to more drastically deprecate legacy module systems after which we can likely simplify package layout and build processes. But again, not set in stone, as long as we have these exports fields in v6 I'm going to be happy. And if we're comfortable to deprecate commonjs sooner, all the better, I don't think it's just a code infra decision. In any case, PRs like this one that remove optionality in the build process and that adopt a more uniform package layout are always welcome IMO. * "the exports field" or "the minimum that is necessary to load correctly under vite/node" |
🤞 This will sail smoothly, it's great to be in a place with less permutations to consider. |
From #39882 (comment).