[pickers] Add codemods for breaking changes

[LukasTy]

The v6 for pickers is bringing quite a few breaking changes.
To ease users' migration we ought to try and cover as most changes with codemods as possible.

The codemod package can be found here. It already contains all the core setup needed in order to add new codemods to it.

This is intended as an umbrella issue to group all the codemods needed for v.6.x migration.
Ideally as much migrations as possible should be provided with preset-safe codemod.

The process of adding a new codemod

• One of the existing codemods can be used as an example (i.e.: localization-provider-rename-locale)
• copy or create a new folder for your codemod
• all the relevant code that is eventually shipped to the user is in index.ts
• update/provide tests for your newly created codemod (test fixtures are authored as js files to allow as minimal syntax as you want—without triggering ts issues)
• if your codemod is safe to add to preset-safe—update this codemod with your newly added codemod making sure the codemods order is correct if codemod is sensitive to that (i.e. separate props should firstly be migrated to componentProps and only later be passed through a codemod renaming componentProps to slotProps if we'd go with such approach)
• update README file with your newly added codemod
  You can check @mui/codemod for inspiration on more advanced migration cases.

How to test your changes locally (on a different project)

P.S. yarn link does not create a bin command from a linked package

• run build with either yarn workspace @mui/x-codemod build or yarn build if you are in src/packages/x-codemod
• run cd build && yarn pack
• copy the built 7.tgz file to the root of your project you want to run (test) the codemod in
• add "@mui/x-codemod": "file:./<your_package_name>" into your project dependencies
• run yarn install
• now you can run the codemod in the way you prefer (either through npx @mui/x-codemod v6.0.0/preset-safe src or by adding an x-codemod script in your project)
• caveat: testing iterative changes might result in a cached package version being used instead of your latest modification. You can either use a unique package name (possibly quicker) each time or clean npm cache each time.

Breaking changes requiring codemods

Breaking changes related to pickers are documented here and relevant PRs are available with applied filters.

• replace-left-arrow-button-slot doc | change PR
• replace-right-arrow-button-slot doc | change PR
• replace-dialog-prop doc | change PR
• replace-paper-prop doc | change PR
• replace-popper-prop doc | change PR
• replace-transition-component-prop doc | change PR
• replace-trap-focus-prop doc | change PR
• replace-render-day (optional) doc | change PR — possibly very hard or impossible to make a reliable codemod
• rename-localization-props doc | change PR
• rename-locale-prop doc | change PR
• rename-view-components doc | change PR | change PR
• rename-date-prop-on-view-components doc | change PR
• rename-private-components (optional) doc | change PR
• replace-toolbar-props-by-slot doc | change PR | change PR
• replace-tabs-props doc | change PR | change PR
• replace-adapter-imports doc | relevant issue
• rename-should-disable-time doc | change PR
• rename-next-components (optional) doc | change PR
• rename-input-format-prop doc | change PR

[alexfauquette]

For the localeText prop, I should import: mui/material-ui#34430

[alexfauquette]

@LukasTy About rename-should-disable-time I don't know if we can do a codemod, or at least it should be not be in preset since there are two options to do the migration.

By the way, there is a typo in the migration example: The argument name is time, but the method uses value. I don't know which one is the best

 <DateTimePicker
-  shouldDisableTime={(timeValue, view) => view === 'hours' && timeValue < 12}
+  shouldDisableTime={(time, view) => view === 'hours' && value.hour() < 12}
 />

About rename-private-components and rename-next-components it's feasible to have a codemod, but it will not be that much different from a search and replace.

[LukasTy]

About rename-should-disable-time I don't know if we can do a codemod, or at least it should be not be in preset since there are two options to do the migration.

I do think that we should do the migration from shouldDIsableTime to shouldDisableClock as that is safe and shouldn't cause any issues.
But yes, the fact that the new shouldDisableTime is now more flexible should still be made clear 🙈

By the way, there is a typo in the migration example: The argument name is time, but the method uses value. I don't know which one is the best

🤦 I do think that value does sound a bit more correct, just because time.hour() seems a bit strange 🙈

About rename-private-components and rename-next-components it's feasible to have a codemod, but it will not be that much different from a search and replace.

Indeed, those are somewhat pointless as codemods and would probably cover a very small percentage of use-cases anyways. 👌
I do agree that they can be omitted from the package. 👍

[alexfauquette]

OK, I will do the missing one + fix migration guide 👍

[LukasTy]

Closing this one as all the planned codemods for stable release have been added. 👍
If we will need any further improvements or fixes, they can be tackled via separate issues.