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

[codemod] Add optimal-imports for v5 #27404

Merged
merged 14 commits into from Jul 26, 2021

Conversation

mnajdova
Copy link
Member

@mnajdova mnajdova commented Jul 22, 2021

Add optimal-imports codemod compatible with v5. It is included in the preset-safe codemod.

@mui-pr-bot
Copy link

mui-pr-bot commented Jul 22, 2021

No bundle size changes (experimental)

Generated by 🚫 dangerJS against f6a89e7

Comment on lines 7 to 9
import TableContext from '@material-ui/core/Table/TableContext';
import TabScrollButton from '@material-ui/core/Tabs/TabScrollButton';
import SwitchBase from '@material-ui/core/internal/SwitchBase';
Copy link
Member Author

Choose a reason for hiding this comment

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

Not sure if these should be ignored or not, but I've added them as they were there in the v4.0.0/optimal-imports. I've listed potential solutions to this in the PR description.

Copy link
Member

@eps1lon eps1lon left a comment

Choose a reason for hiding this comment

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

This looks good so far. Could use some test what happens if we already have an import from @material-ui/core/colors or what happens if we have two private imports for the same source.

And the sorting is also not tested. It's not clear to me whether we want to sort alphabetically (the code could be more explicit here instead of .sort()) or keep the imports as they appeared in the original source.

If people need them sorted, then they can use other lint plugins.

};

root.find(j.ImportDeclaration).forEach((path) => {
if (path.value.importKind && path.value.importKind !== 'value') return;
Copy link
Member

Choose a reason for hiding this comment

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

these are easy to miss.

Going to add a lint rule though that requires braces for single-statement ifs

@oliviertassinari
Copy link
Member

None of these are exported from their parent directory, so the codemod basically breaks these imports

They have always been private, AFAIK, I would almost advocate for removing the imports, but what we currently do, by ignoring them sounds great too.

@oliviertassinari oliviertassinari removed their request for review July 22, 2021 12:16
@mnajdova
Copy link
Member Author

mnajdova commented Jul 22, 2021

They have always been private, AFAIK, I would almost advocate for removing the imports, but what we currently do, by ignoring them sounds great too.

@oliviertassinari the codemod is currently NOT ignoring them, but I could make a list of the imports we want to still support and they can be ignored.

@mnajdova mnajdova requested a review from eps1lon July 22, 2021 15:16
Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
@eps1lon eps1lon changed the title [codemod] Add private-imports codemode for v5 [codemod] Add private-imports for v5 Jul 23, 2021
@mnajdova

This comment has been minimized.

@mnajdova
Copy link
Member Author

@eps1lon I believe it is good to go now. I've basically just copied the optimal-imports and replaced /es/ with /modern/ in the paths.

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Jul 24, 2021
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Jul 26, 2021
@eps1lon
Copy link
Member

eps1lon commented Jul 26, 2021

@eps1lon I believe it is good to go now. I've basically just copied the optimal-imports and replaced /es/ with /modern/ in the paths.

It's still unclear from the PR description and name what this codemod is supposed to do. If this is just v4.0.0/optimal-imports then name it as such (v5.0.0/optimal-imports). But we don't want to touch private imports at all since we couldn't convert them anyway (otherwise they're not private).

@mnajdova
Copy link
Member Author

It's still unclear from the PR description and name what this codemod is supposed to do. If this is just v4.0.0/optimal-imports then name it as such (v5.0.0/optimal-imports). But we don't want to touch private imports at all since we couldn't convert them anyway (otherwise they're not private).

We could rename it to optimal-imports, I've renamed it to private-imports because of #27321 (comment)

@mnajdova mnajdova changed the title [codemod] Add private-imports for v5 [codemod] Add optimal-imports for v5 Jul 26, 2021
@eps1lon
Copy link
Member

eps1lon commented Jul 26, 2021

We could rename it to optimal-imports, I've renamed it to private-imports because of #27321 (comment)

I would ignore that statement since it is based on some false assumptions and statements that are missing context:

In v4, we have introduced a codemod https://github.com/mui-org/material-ui/blob/next/packages/material-ui-codemod/README.md#optimal-imports to migrate ALL these private import instances.

We do not migrate all: https://github.com/mui-org/material-ui/blob/4b128c53b895b863e5fd7c4069b53c1598203421/packages/material-ui-codemod/src/v4.0.0/optimal-imports.test/expected.js#L59-L61

optimal suggests that it's optional, it's not.

The same applies to the v4 version. The problem still stands that we can't codemod private imports. We could only remove these imports which would break the build (which makes the codemod not suitable for preset-safe). Instead, we should add a lint rule for path imports that has a fixer for those path imports that are available via public paths.

But that's probably out-of-scope. For now we just want the same implementation of optimal-imports so let's document it as such (PR descriptions are important). optimal-imports was not a good name, private-imports is just as much but these days "concerns" seem to matter more. If somebody feels strongly about their concerns we can go with either name since I don't think the naming matters.

The problem was that the PR description was incomplete so all I could go off was the name and the name was inaccurate.

Copy link
Member

@siriwatknp siriwatknp left a comment

Choose a reason for hiding this comment

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

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants