-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[charts] Use vendor to have CJS working out of the box #13608
base: master
Are you sure you want to change the base?
Conversation
Deploy preview: https://deploy-preview-13608--material-ui-x.netlify.app/ Updated pages: |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
- run: | ||
name: Build charts vendor | ||
command: node ./packages/x-charts-vendor/scripts/build.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.
We need to build the package each time. Otherwise the folder is empty and so every script complains that the package does not exist
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.
Should we provide the package built already instead of having to build it in the pipelines and docs?
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.
This would create an inconsistency in the release:
- For not the
@mui/x-charts-vendor
is not published so no preview could work - The preview would used the last released version of the
@mui/x-charts-vendor
which is not practical if you need to bump one of the d3-lib
- install_js | ||
- run: | ||
name: Tests charts | ||
command: pnpm test:charts:unit # Run special test for charts due to ESM compatibility issue | ||
- run: |
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.
Thos test are now in unit test since it does not require any specific babel config
@@ -23,6 +24,7 @@ | |||
"@mui/x-date-pickers": "packages/x-date-pickers/build", | |||
"@mui/x-date-pickers-pro": "packages/x-date-pickers-pro/build", | |||
"@mui/x-charts": "packages/x-charts/build", | |||
"@mui/x-charts-vendor": "packages/x-charts-vendor", |
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.
Not sure it's usefull to ask circle ci to build it 🤔
@@ -6,6 +6,7 @@ netlify/functions | |||
/docs/pages/playground/ | |||
/lerna.json | |||
/packages/x-codemod/src/**/*.spec.js | |||
/packages/x-charts-vendor |
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.
Except the script all the files are automatically generated, so I just skipped the entire folder
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 would argue it is useful for the script itself to be linted 😅
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.
It's a copy past of victory-vendor so it nearly respect non of our linting rules. But could do it in a cleanup phase
@@ -5,7 +5,7 @@ | |||
"author": "MUI Team", | |||
"license": "MIT", | |||
"scripts": { | |||
"build": "rimraf ./export && cross-env NODE_ENV=production next build --profile && pnpm build-sw", | |||
"build": "rimraf ./export && node ../packages/x-charts-vendor/scripts/build.js && cross-env NODE_ENV=production next build --profile && pnpm build-sw", |
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.
Build the vendor package otherwise netlify has no access to it
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.
This currently means all our devs need to build the lib before we can run pnpm docs:dev
, else docs can't find the files. We probably need to run it on the dev
command as well 🤔
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 assumed that once merged, everybody would run the build, and then it's done since all the generated files are in .gitignore
But effectively it's not friendly for external contributors. Maybe adding a parameter such that build.js chached
check if some files already exist. if yes it just skip the build. Such that when running dev, we don't lose time generating this package
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.
Yeah, maybe check if the entrypoints are present and run the script otherwise?
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.
It also breaks when running tests btw
packages/x-charts-vendor/.babelrc.js
Outdated
? path.resolve(__dirname, `./lib-vendor/${match.groups.pkg}/index.js`) | ||
: path.resolve(__dirname, `./lib-vendor/${match.groups.pkg}/src/index.js`); | ||
|
||
console.log({ vendorPkg }); |
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.
console.log({ vendorPkg }); |
const vendorPkg = ['delaunator', 'robust-predicates'].includes(match.groups.pkg) | ||
? path.resolve(__dirname, `./lib-vendor/${match.groups.pkg}/index.js`) | ||
: path.resolve(__dirname, `./lib-vendor/${match.groups.pkg}/src/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.
Here is the main difference with the original script.
d3-delaunay
requires delaunator
which requires robust-predicates
which seems to be ESM only too.
So I added the to the vendor too.
Those lines are here because they do not have the exact same structure as the d3 packages
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
- run: | ||
name: Build charts vendor | ||
command: node ./packages/x-charts-vendor/scripts/build.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.
Should we provide the package built already instead of having to build it in the pipelines and docs?
@@ -6,6 +6,7 @@ netlify/functions | |||
/docs/pages/playground/ | |||
/lerna.json | |||
/packages/x-codemod/src/**/*.spec.js | |||
/packages/x-charts-vendor |
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 would argue it is useful for the script itself to be linted 😅
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
@@ -5,7 +5,7 @@ | |||
"author": "MUI Team", | |||
"license": "MIT", | |||
"scripts": { | |||
"build": "rimraf ./export && cross-env NODE_ENV=production next build --profile && pnpm build-sw", | |||
"build": "rimraf ./export && node ../packages/x-charts-vendor/scripts/build.js && cross-env NODE_ENV=production next build --profile && pnpm build-sw", |
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.
This currently means all our devs need to build the lib before we can run pnpm docs:dev
, else docs can't find the files. We probably need to run it on the dev
command as well 🤔
Related issues
Would fix [charts][ESM]
@mui/x-charts
does not work with jest #11568 -: with the following modification the error is gone test-victory-vendor alexfauquette/mui-x-charts-jest-issue-minimal-reproduction#1For [charts][ESM] Can't import @mui/x-charts under node.js #11016 we still have some import issue: https://stackblitz.com/edit/stackblitz-starters-okvxu3?file=package.json,index.mjs
I had to do the following modification to have the example work (plus adding share dependencies)
Fix [charts][ESM] Doesn't build in Next.js due to require() of ES Module (ERR_REQUIRE_ESM) #9826
https://codesandbox.io/p/devbox/elegant-forest-hvn8fk?file=%2Fnext.config.js%3A7%2C42&workspaceId=d214a4af-c616-40eb-ac12-807102cf00db
Allows to integrate charts unit test with others since the babel hack is not needed anymore
What has been done
I copy pasted the victory-vendor script and adapted it such that it includes all the d3 lib we need (colors, interpolation, scale)
I did not used directly the
victory-vendor
package because they use the legacyd3-voronoid
and we are using the newd3-delaunay
.The
d3-delaunay
is a wrapper on top ofdelaunator
which relies onrobust-predicates
. This last one seems to also be only ESM so I added both of them to the script such that they are correctly imported for CJSOpen question
Is it a breaking change? I don't hink so, because if user are woking with ESM this vendor should be transparent. ANd if they were transpiling d3 modules now they don't need because we do it for theme
TODO if we agree on the strategy