-
-
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
[core] Only define aliases once for TypeScript and once for Webpack + Babel #35197
Conversation
Signed-off-by: Matheus Wichman <[email protected]> Signed-off-by: Olivier Tassinari <[email protected]> Co-authored-by: Olivier Tassinari <[email protected]>
Netlify deploy previewhttps://deploy-preview-35197--material-ui.netlify.app/ Bundle size report |
@@ -133,43 +133,6 @@ module.exports = function setKarmaConfig(config) { | |||
envName: 'stable', | |||
}, | |||
}, | |||
// transpile 3rd party packages with dependencies in this repository |
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.
The tests are passing without it
I think it is not needed since we don't have pickers tests on the core anymore
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 it again for the tree view 😆
@@ -55,13 +34,6 @@ module.exports = { | |||
'babel-plugin-optimize-clsx', | |||
// for IE11 support | |||
'@babel/plugin-transform-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.
It now uses the TypeScript aliases
https://nextjs.org/docs/advanced-features/module-path-aliases
@@ -0,0 +1,4 @@ | |||
import { Requireable } from 'prop-types'; | |||
|
|||
declare const integerPropType: Requireable<number>; |
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.
TS was complaining that integerPropType
had no typing file when I moved to composite
build
@@ -13,8 +13,8 @@ | |||
"include": ["./src/**/*.ts*"], | |||
"exclude": ["src/**/*.spec.ts*", "src/**/*.test.ts*"], | |||
"references": [ | |||
{ "path": "../mui-utils/tsconfig.build.json" }, |
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 had to fix the references
in all the packages, otherwise TS was not able to resolve correctly the imports.
Not sure why it is impacted by the new structure
docs/next.config.js
Outdated
'@mui/joy': '../packages/mui-joy/src', | ||
}, | ||
// transformFunctions: ['require'], | ||
alias: getMuiAliases('src'), |
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.
Now that aliases moved to webpack (through typescript paths), is this aliasing still necessary?
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.
Yes it seems. In Toolpad we don't use typescript paths, but do aliasing directly in webpack. I believe then it gets picked up under node_modules
as well and this babel plugin should become 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.
For the core these aliases are needed to make sure that when we use X components on the marketing werbsite, the @mui/material
(& co) imports from @mui/x-date-pickers
/ @mui/x-data-grid
are using the local one and not the one from their node modules (which causes issues).
But if we have a way to say to Next to also resolve some node modules with the TS aliases, that would be great
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.
But if we have a way to say to Next to also resolve some node modules with the TS aliases, that would be great
Not with TS aliases I believe. But with webpack aliases it seems to work that way
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.
But we don't have any webpack alias defined no ?
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 probably won't be able to get rid of the typescript paths soon as it will be necessary for vscode. But I'd already consider it a win if we can remove them from babel
everywhere. Even if that means moving it to webpack, at least it would be where it makes sense.
The real solution is to update our build process in a way that we can rely on yarn workspace linking to resolve local packages. That way we can get rid of all aliasing. There's other obstacles though that currently block us from going there (mainly the build folders that contain the published packages with their subpath 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.
I struggle to apply the webpack aliases on the node_modules, if you have an idea on how to do it (to be able to drop babel which is necessary for notistack and the X deps)
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 updated #33199 and it still seems to work. Check out the changes to next.config.js without whitespace: https://github.com/mui/material-ui/pull/33199/files?diff=split&w=1#diff-97081d4c5e67d7fb92c87085affbac02322e2b4c53c01c5e65f500fc3b67a402
and babel.config.js: https://github.com/mui/material-ui/pull/33199/files?diff=split&w=1#diff-2ed4f5b03d34a87ef641e9e36af4a98a1c0ddaf74d07ce93665957be69b7b09a
Will give a quick try if I can replace next-transpile-modules
with the upcoming built-in transpilePackages
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 but I guess it will only works with the doc, we will still have to keep babel for the testing.
That's still a win for sure.
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.
Yes, sorry for the confusion, I'm only talking about the docs here. It's the only thing we have to deal with from Toolpad's perspective
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 didn't notice anything that could go wrong. Nice cleanup with the karma config file.
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.
Overall looks like a great cleanup. I would recommend resolving Olivier's comments about the function args before merging.
@flaviendelangle Could you recheck again? |
6475ec1
to
78b17d7
Compare
@flaviendelangle Do you have an idea which specific build/test/lint flows break when we remove the babel aliasing? Just for me to know what makes sense to concentrate on next in code infra? |
I did not test it in a long time but I'd say the doc building scripts should breaking |
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.
Great step in the unification of aliases! A potential next lowish hanging fruit could be shifting eslint resolver from webpack to typescript paths through eslint-import-resolver-typescript
'typescript-to-proptypes': path.resolve(__dirname, './packages/typescript-to-proptypes/src'), | ||
docs: path.resolve(__dirname, './docs'), | ||
}, | ||
alias: getMuiAliases({ type: 'src', useESIcons: true }), |
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.
One thing that could be worth a try is reading them from tsconfig
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.
If we can drop the babel aliases, I guess we could have the tsconfig as the single source of truth.
Would you be ok to keep it for a follow up?
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.
Yes absolutely, this just popped in my head
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.
The direction looks nice 👍
{ | ||
test: /\.(js|mjs|jsx)$/, | ||
include: | ||
/node_modules(\/|\\)(notistack|@mui(\/|\\)x-data-grid|@mui(\/|\\)x-data-grid-pro|@mui(\/|\\)x-license-pro|@mui(\/|\\)x-data-grid-generator|@mui(\/|\\)x-date-pickers-pro|@mui(\/|\\)x-date-pickers|@mui(\/|\\)x-tree-view)/, | ||
include: /node_modules(\/|\\)@mui(\/|\\)x-tree-view/, | ||
use: { |
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 miss notistack here no? https://mui.com/material-ui/react-snackbar/#notistack.
Ah, same for data grid, and all MUI X components no?
This logic is meant to help us test fixes for these components, make sure if we break something in Material UI for MUI X, we know it as soon as we work on the PR, not once Material UI is released and MUI X updates it dependencies.
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 logic is meant to help us test fixes for these components, make sure if we break something in Material UI for MUI X, we know it as soon as we work on the PR
But we don't have any test using those components right?
If the tests pass without the alias.
I can add the alias back, but it will never be used.
@flaviendelangle Just stumbled upon this PR again and realized it has been superseded by #40792 (or at least part of it). Apologies, I think I forgot about the existence of this PR while building that. |
I need to go back to it and see if some of it still make sense 😆 |
Goals
babel.config.js
for the doc to hopefully one day be able to use SWC (other plugins already have issues like swc support oliviertassinari/babel-plugin-transform-react-remove-prop-types#201 or Include "babel-plugin-react-remove-properties" functionality swc-project/swc#6057)Side note
@mui/docs
andmodules
contains almost nothing, maybe we could reduce the amount of aliases (and therefore make the overall architecture easier to understand) in the future.