[pickers] Remove the defaultCalendarMonth prop

[flaviendelangle]

Closes #10986

I have two questions here:

1. I forgot to deprecate this prop when releasing referenceDate. Do you think it's a good enough reason to postpone its removal to v8? The migration to referenceDate is very straightforward and the prop is not widely used so I'd say it's fine but if you want we can keep it another year.

2. Should we codemod it and add it to the preset-safe? This is not a 1-on-1 behavior since the referenceDate also applies to other views, so it could lead to unwated behavior. Should we create the codemod but let people run it if they want?

Changelog

Breaking changes

• The deprecated defaultCalendarMonth prop has been removed in favor of the more flexible referenceDate prop.

  - <DateCalendar defaultCalendarMonth={dayjs('2022-04-01')};
  + <DateCalendar referenceDate{dayjs('2022-04-01')} />

[mui-bot]

Deploy preview: https://deploy-preview-10987--material-ui-x.netlify.app/

Updated pages:

• docs/data/migration/migration-pickers-v6/migration-pickers-v6.md

Generated by 🚫 dangerJS against 4fdd6b0

[alexfauquette]

I forgot to deprecate this prop when releasing referenceDate. Do you think it's a good enough reason to postpone its removal to v8? The migration to referenceDate is very straightforward and the prop is not widely used so I'd say it's fine but if you want we can keep it another year.

For me you can remove defaultCalendarMonth. The pain of replacing it with referenceDate is a small breaking change.

Should we codemod it and add it to the preset-safe? This is not a 1-on-1 behavior since the referenceDate also applies to other views, so it could lead to unwated behavior. Should we create the codemod but let people run it if they want?

Not sure it's worth creating a codemod if not in preset-safe. The reason is that I'm reading the breaking change. If I need to think, it's better to have the part of the codebase using it under my eyes. So I would prefer to do a search in the codebase to know where I'm using defaultCalendarMonth to think what should I change.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[LukasTy]

1. I forgot to deprecate this prop when releasing referenceDate. Do you think it's a good enough reason to postpone its removal to v8? The migration to referenceDate is very straightforward and the prop is not widely used so I'd say it's fine but if you want we can keep it another year.

WDYT about deprecated it after the fact - add the deprecation in v5 just now.
Imagine users using v6 maybe for 6 or 12 months after the release of new stable. They'd see the deprecation warning and potentially migrate to the referenceDate before upgrading to v7. 🤔

2. Should we codemod it and add it to the preset-safe? This is not a 1-on-1 behavior since the referenceDate also applies to other views, so it could lead to unwated behavior. Should we create the codemod but let people run it if they want?

I'd be in favor of creating the codemod if it's not that difficult. 🤔
As for adding it into the preset-safe. Well, that's debatable. We could omit it just for the sake of complete correctness, although, I'd imagine, that almost no one would mind the slight change of behavior. 🙈 🤷

[flaviendelangle]

WDYT about deprecated it after the fact - add the deprecation in v5 just now.

To deprecate it on the next v6 patch?
It's a good idea!

[LukasTy]

WDYT about deprecated it after the fact - add the deprecation in v5 just now.

To deprecate it on the next v6 patch? It's a good idea!

Yes, that's exactly my idea. 🤔
IMHO, it's way better than just removing the prop without deprecation and probably better than keeping it deprecated on v7. 🙈

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[flaviendelangle]

@LukasTy #11138

[LukasTy]

LGTM! 👏