-
-
Notifications
You must be signed in to change notification settings - Fork 32.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
[test] Split the test package #39061
Conversation
a629632
to
5531c65
Compare
Netlify deploy previewhttps://deploy-preview-39061--material-ui.netlify.app/ Bundle size report |
@@ -211,15 +211,6 @@ module.exports = { | |||
rules: { | |||
// does not work with wildcard imports. Mistakes will throw at runtime anyway | |||
'import/named': 'off', | |||
'no-restricted-imports': [ |
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.
No need to do this anymore as package.json's export
field controls visibility of exports.
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.
Which linting process is now controlling this? The typescript type checker?
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.
Node doesn't allow importing arbitrary files from the package when any subpath exports are defined.
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.
Ok, 👍 that assumes there is at least one Node.js process importing this natively
"noUnusedLocals": true, | ||
"skipLibCheck": true, | ||
"esModuleInterop": true | ||
"esModuleInterop": true, | ||
"moduleResolution": "node16", |
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 lets TS respect the exports
field in other packages (making adding the new package to root tsconfig's paths unnecessary).
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.
Ok, so as a first step it's getting all the imports in order without really touching the implementation. So if I understand correctly, the only cycle that is really left is one between test
and @mui/test-utilities
? Which will be tackled separately? (I really like this style of development, especially for code infra stuff which often touches a lot of code, makes things much easier to review)
If I had to nit about one thing it'd be about nomenclature. Across the codebases we tend to name these packages/folders "utils" not "utilities".
No, there's no cycle between them. The ones remaining are between [@mui/material, @mui/base, @mui/joy] and @mui-internal/test-utilities as the describeConformance utilities use components from these packages. I'll open a separate PR for this as it requires some code changes.
Actually, I named this package after |
This is a step towards removing circular package dependencies.
This PR splits the
test
package into two:@mui-internal/test-utils
(that live under the packages directory) and@mui-internal/tests
(which remains under the test directory).@mui-internal/test-utils
contains the files from the old test/utils directory.I renamed the remains to
@mui-internal/tests
, astest
is the name of Node's built-in package.This PR does not remove the actual dependency cycles. It requires refactoring of several modules under test-utils. I'll open a separate PR for this.