-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
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 accordion props deprecation #40771
Conversation
Netlify deploy previewhttps://deploy-preview-40771--material-ui.netlify.app/ Bundle size report |
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.
Thanks for working on this @siriwatknp!
The new file restructure makes sense to me.
@mnajdova, this is the way we envision deprecation codemods working: Deprecations might not be tied to a specific version, for example, the Accordion
ones from this PR will exist in v5 and v6. The idea is to have a deprecations codemod that holds all current deprecations of the stable version.
- Whenever we add a deprecation, we add the respective codemod to the deprecations codemods.
- Whenever a deprecated API is removed and becomes a breaking change, that codemod is copied over to the version of the breaking change. For example, if
TransitionComponent
is removed in v7, theaccordion-props
codemod is copied to the v7 codemods. When v7 becomes the stable version, that codemod is removed from the deprecation codemods.
Users on the stable version would be able to run deprecations/all
codemod any time they need to, as these should be idempotent. This way we can also start testing codemods as soon as possible, when the deprecation comes out.
The same goes for the migration guide.
What do you think?
Makes sene! 👍 |
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.
Hey! I left a couple of comments 😊
Also a question: I tried running the codemod locally to modify the test cases (just to try it out), and it modifies tests-cases/actual.js
as expected, but it doesn't modify test-cases/theme.actual.js
. You know why that might be?
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 file should be index.js
, right? Or have an index file that reexports it. Otherwise, it won't be found here when running transform deprecations/all
const actual = transform( | ||
{ | ||
source: read('./test-cases/actual.js'), | ||
path: require.resolve('./test-cases/actual.js'), |
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.
What's the difference between the source
and the path
properties? I couldn't find any reference to path
inside the transform
function.
Another question regarding codemods, the my-library/
├── my-components/
│ ├── my-accordion.tsx If I run the codemod on the |
Yes, that's right. |
I figured it out: the difference lies in the AST parsing. For some reason, when I run the codemod locally the |
I figured out that the test is not correct, it should use |
@DiegoAndai I think it's good to go. I added a CONTRIBUTING.md in this PR as well because I always forget about the steps and script when testing locally. |
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.
Looks good, there's two test cases that seem not to work
packages/mui-codemod/CONTRIBUTING.md
Outdated
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.
Very useful!
// case 1: import ComponentName from '@mui/material/ComponentName'; | ||
// case 2: import { ComponentName } from '@mui/material'; | ||
// case 3: import { ComponentName as SomethingElse } from '@mui/material'; |
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.
Nice that we cover these! Good catch
<Accordion slots={{ root: 'div' }} slotProps={{ root: { className: 'foo' } }} />; | ||
<MyAccordion slots={outerSlots} slotProps={outerSlotProps} />; |
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 looks like it's not working. The transition
keys are not getting added.
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.
Nice catch, fixed!
…mod/deprecations
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.
Thanks for taking this 🙌🏼
…mod/deprecations
part of #40417
transformation:
existing
slots
andslotProps
are also handled.Note
Adjusting the codemod structure a bit. It was really painful in v5 to navigate between codemod (the implementation and test cases are separated in different folder.
Moving forward, I think the implementation and test cases should be in the same folder. This is just a DX improvement for our team, there is no impact on consumers.
So from:
to: