[RFC] Migrate date pickers from the lab to MUI X

[oliviertassinari]

This issue is meant to give a space to discuss moving the date picker components from the lab to MUI X.
I propose that once we assign a full-time product & engineering owner on them, we do the move, and expose the components as:

• @mui/x-pickers
• @mui/x-pickers-pro

The component is currently a shared responsibility of the core team, where Sebastian has lately been the one spending the most time on them.

Advantages:

• If we continue with the date range picker inside the Pro plan, it seems simpler to isolate the whole codebase here, to keep the core fully MIT.
• The core has been successful up until now without these date pickers components. Moving them here would allow the core team to focus on the DX and the design dimensions on the core. From what I understand, it's what is ultimately better aligned with the success of the product this team focuses on
• It would allow giving more development bandwidth to the date pickers. It feels like there is a significant backlog of problems that we could focus on, but it's currently hard to balance time between the date picker and the other core components.

Disadvantages:

• One could argue that the last time we moved the components from mui-org/material-ui-pickers to *mui-org/material-ui" it was a mess. We ended up having to update a lot of the code of the component. I personally that this was great. It forced us to make the picker components consistent with the other ones. While the same applies here? Yes, likely. I do expect that the migration won't be very smooth. However, what I hope is the opposite outcome as in the previous migration. Meaning, we won't touch the component but it will force us to make sure MUI X has the same development environment as the main repository.
• One could argue that the core should own any component that has a native counterpart. Why? I didn't follow the reasoning so I would leave this to who wants to defend the argument.
  Instead, I can argue why the opposite might work better: Bootstrap is successful with few components. Focusing on too many components in the core feels risky, it could prevent the team to focus on what has more impact: the DX for the most common use cases, the design appeal, and the ease of customizations.

[oliviertassinari]

We are moving forward with this RFC. We are in the process of moving the pickers to @mui/x-pickers and the date range picker to @mui/x-pickers-pro. @flaviendelangle is leading this initiative.

A couple of tasks that could make sense in sequential order before starting the work:

• Bring all the pickers GitHub labels in MUI X
• Update the code infrastructure in MUI X to bring what's missing from MUI Core
• Transfer all the relevant issues from https://github.com/mui-org/material-ui and https://github.com/mui-org/material-ui-pickers to https://github.com/mui-org/material-ui-x

Two options to work on the pickers once the above done:

Option 1

• Move the code from @mui/lab to the new package
• Migrate the docs to MUI X
• Have the community update their imports

  -import { DatePicker } from '@mui/lab';
  +import { DatePicker } from '@mui/pickers';

• Continue work on the pickers from MUI X

Option 2

• Restart the date picker from scratch from MUI X

Option 3

• Fork an existing MIT date picker that is of much better shape than ours, and continue the work from there.

[flaviendelangle]

In Option 1, I made a few changes (see PR description).

I think we can wait 2-3 weeks before releasing an alpha.
During this time we decide how deep we want to change the components.
If we want to keep some big parts (option 1), we release an alpha with almost no changes compared to the lab and iterate on it.
If we want to rewrite almost everything (option 2), we don't release to avoid making the community migrate for something that won't remain accessible in the future releases.

Does it sound OK to you ?

[joserodolfofreitas]

First of all, I think it's perfect that the component was previously in a "lab" package.
And the lab being a sort of incubator, Option 1 makes more sense to me.
In this sense, (when we move a component out of lab)*, we're acknowledging it's solid (and powerful) enough to join MUI X.

[joserodolfofreitas]

I'm not sure why we would rewrite the DatePicker from scratch, but in case we decide going with option 2, meaning it's not solid or powerful enough, and we're moving the component mostly to have a new one under MUI-X umbrella, would it make sense to have an x-lab and move there first?

[oliviertassinari]

(when we move a component out of lab)*, we're acknowledging it's solid (and powerful) enough to join MUI X.

@joserodolfofreitas to precise it, the date picker is currently not great. In X, it would still be in an alpha version so we can make heavy BCs where needed.

would it make sense to have an x-lab and move there first?

I think that @mui/x-lab only make sense if we have a @mui/x package (which we could imagine having). The purpose of the lab in the core is only one thing: semver. If we have a @mui/x-pickers package, then we can already have the semver we need for BCs.

From a strategic perspective, so far, we decided against @mui/x to better compete with third-party libraries in the space. It allows the community to have social proofs of usage with the npm stats, at the cost of having more packages to install. Is this the right call? We can always challenge it. In MUI Core, people would hate us if they had to install 20 packages, one for each component (even with 5, they say it's already too much).

[flaviendelangle]

I think that @mui/x-lab only make sense if we have a @mui/x package

I agree, as long as we have dedicated packages, we just have to keep the unstable packages in alpha.
As for the 1 package vs 1 package per set of components, I think both can make sense. But I would advise against switching our strategy now, we renamed a few months ago and changing again would feel unpleasant to our community.