Skip to content
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

Closed
wants to merge 17 commits into from

Conversation

flaviendelangle
Copy link
Member

@flaviendelangle flaviendelangle commented Nov 18, 2022

Goals

  1. Define the path leading to the packages in as little places as possible to avoid missing aliases and make the architecture easier to understand.
  2. Reduce our usage of 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 and modules contains almost nothing, maybe we could reduce the amount of aliases (and therefore make the overall architecture easier to understand) in the future.

@flaviendelangle flaviendelangle self-assigned this Nov 18, 2022
@flaviendelangle flaviendelangle added the core Infrastructure work going on behind the scenes label Nov 18, 2022
@mui-bot
Copy link

mui-bot commented Nov 18, 2022

Netlify deploy preview

https://deploy-preview-35197--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against ac3878d

@flaviendelangle flaviendelangle changed the title [core] Use TypeScript aliases instead of Babel aliases for the doc [core] Only define aliases one for TypeScript and for Webpack + Babel Nov 18, 2022
@flaviendelangle flaviendelangle changed the title [core] Only define aliases one for TypeScript and for Webpack + Babel [core] Only define aliases once for TypeScript and once for Webpack + Babel Nov 18, 2022
@@ -133,43 +133,6 @@ module.exports = function setKarmaConfig(config) {
envName: 'stable',
},
},
// transpile 3rd party packages with dependencies in this repository
Copy link
Member Author

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

Copy link
Member Author

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',
[
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -0,0 +1,4 @@
import { Requireable } from 'prop-types';

declare const integerPropType: Requireable<number>;
Copy link
Member Author

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" },
Copy link
Member Author

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

@flaviendelangle flaviendelangle marked this pull request as ready for review November 22, 2022 09:06
@flaviendelangle flaviendelangle requested review from mnajdova, Janpot and oliviertassinari and removed request for Janpot November 22, 2022 09:06
'@mui/joy': '../packages/mui-joy/src',
},
// transformFunctions: ['require'],
alias: getMuiAliases('src'),
Copy link
Member

@Janpot Janpot Nov 22, 2022

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?

Copy link
Member

@Janpot Janpot Nov 22, 2022

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.

Copy link
Member Author

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

Copy link
Member

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

Copy link
Member Author

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 ?

Copy link
Member

@Janpot Janpot Nov 22, 2022

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).

Copy link
Member Author

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)

Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member

@Janpot Janpot Nov 23, 2022

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

Copy link
Member

@oliviertassinari oliviertassinari left a 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.

scripts/muiAliases.js Outdated Show resolved Hide resolved
@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Dec 2, 2022
Copy link
Member

@mnajdova mnajdova left a 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.

@siriwatknp
Copy link
Member

@flaviendelangle Could you recheck again?

@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Sep 21, 2023
@Janpot
Copy link
Member

Janpot commented Sep 21, 2023

@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?

@flaviendelangle
Copy link
Member Author

@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

Copy link
Member

@Janpot Janpot left a 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 }),
Copy link
Member

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

Copy link
Member Author

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?

Copy link
Member

@Janpot Janpot Sep 21, 2023

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

Copy link
Member

@oliviertassinari oliviertassinari left a 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: {
Copy link
Member

@oliviertassinari oliviertassinari Sep 22, 2023

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.

Copy link
Member Author

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.

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Sep 22, 2023
@Janpot
Copy link
Member

Janpot commented Mar 8, 2024

@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.

@flaviendelangle
Copy link
Member Author

I need to go back to it and see if some of it still make sense 😆

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Infrastructure work going on behind the scenes PR: out-of-date The pull request has merge conflicts and can't be merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants