[internal] Only define aliases once for TypeScript and once for Webpack + Babel#35197
[internal] Only define aliases once for TypeScript and once for Webpack + Babel#35197flaviendelangle wants to merge 17 commits intomui:v5.xfrom
Conversation
Signed-off-by: Matheus Wichman <matheushw@outlook.com> Signed-off-by: Olivier Tassinari <olivier.tassinari@gmail.com> Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
Netlify deploy previewhttps://deploy-preview-35197--material-ui.netlify.app/ Bundle size report |
| envName: 'stable', | ||
| }, | ||
| }, | ||
| // transpile 3rd party packages with dependencies in this repository |
There was a problem hiding this comment.
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.
We need it again for the tree view 😆
| 'babel-plugin-optimize-clsx', | ||
| // for IE11 support | ||
| '@babel/plugin-transform-object-assign', | ||
| [ |
There was a problem hiding this comment.
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.
TS was complaining that integerPropType had no typing file when I moved to composite build
| "include": ["./src/**/*.ts*"], | ||
| "exclude": ["src/**/*.spec.ts*", "src/**/*.test.ts*"], | ||
| "references": [ | ||
| { "path": "../mui-utils/tsconfig.build.json" }, |
There was a problem hiding this comment.
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.
Now that aliases moved to webpack (through typescript paths), is this aliasing still necessary?
There was a problem hiding this comment.
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.
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.
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.
But we don't have any webpack alias defined no ?
There was a problem hiding this comment.
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.
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.
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.
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.
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
oliviertassinari
left a comment
There was a problem hiding this comment.
I didn't notice anything that could go wrong. Nice cleanup with the karma config file.
mnajdova
left a comment
There was a problem hiding this comment.
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.
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.
One thing that could be worth a try is reading them from tsconfig
There was a problem hiding this comment.
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.
Yes absolutely, this just popped in my head
oliviertassinari
left a comment
There was a problem hiding this comment.
The direction looks nice 👍
| 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.
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.
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.jsfor 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/docsandmodulescontains almost nothing, maybe we could reduce the amount of aliases (and therefore make the overall architecture easier to understand) in the future.