[RFC] Integrate the pickers repository back into the main mono-repository

Context

A bit of history, Material-UI has had an agitated history with the date picker. It’s a component we used to support very early in the core, at least, 4 years ago: https://v0.material-ui.com/#/components/date-picker. However, during the v1 rewrite, it was, at some point, decided that the core team didn’t have the bandwidth for it, that it would be better to distribute the ownership. So we decided to leave to the component to the community. It’s where @dmtrKovalenko came in as a savior and filled the gap ✨ with material-ui-pickers. Over the following months, the core team kept strengthening its link with this project, up to a point where Material-UI now financially supports Dmitriy to work on the project’s mission, as of now with a major upgrade of the Date Picker (to v4).

Looking back, we have a list of signals that suggest the date picker is a key component in any UI library:

• The date picker alone has as many downloads on npm as all the lab components combined.
• The 8th most upvoted issue on our repository.
• The date range feature is the 2nd most upvotes issue we have seen (behind styled-components).
• Given the complexity of the component, it’s rearely something any product team build. When they do, it’s rarely great. It can be a “trojan horse” for Material-UI to gain adoption. I have seen it unfold for antd in https://github.com/getredash/redash/pull/2426#discussion_r223013087.

Proposal

In this context, I propose that we merge https://github.com/mui-org/material-ui-pickers into https://github.com/mui-org/material-ui, under the following location: /packages/material-ui-pickers.

Why?

The potential we are missing on: a better integration between the pickers and the core components. https://en.wikipedia.org/wiki/Monorepo provides a good chunk of information on the tradeoff.

From my perspective, it unfolds into:

1. Easier code sharing. Catch bugs between core and pickers on the earliest stage. Empower large scale code refactorting.
2. Easier knowledge sharing. Silos less likely. Consistant API.
3. Consistent documentation. Same UX for the users (demos, API, Algolia etc). If you run the query “react datepicker” on Google (in FR), you will find vuetify date picker (page 7) before you find the documentation (material-ui-pickers.dev).
4. Easier tools sharing. We setup all the dev dependencies and CI/CD tools once.
5. An opportunity to experience new approaches. For instance, from the main repo perspective: components written in TypeScript, Cypress, Percy, Now, etc.

Potential downsides

1. Releases. We will need to sync releases of pickers and core, sync versions which can be a problem on the earliest stages of v4, when possibly we will need to make some patches. However, using a different package @material-ui/pickers solve most of the problem. @eps1lon has proposed to move away from a single release (in terms of GitHub) to multiple ones. So I think that it’s up to us to figure the strategy that work well.
2. Longer CI. Will we need to run all tests for the pickers? We already faced this problem in the past. For instance, we only run the tests of the icons package if the source change. Maybe we could use something similar?
3. Mixed issues and PRs. This is my main point of interogation. I think it would have the biggest impact on @dmtrKovalenko. He will, all a sudden, be “flooded” with the main repository issues flow, it will be overwhelming, at the beginning. On the core side, it wouldn’t made a significant difference. If only GitHub had this feature https://github.community/t5/How-to-use-Git-and-GitHub/Feature-Request-Subscribe-to-notifications-for-specific-Labels/td-p/16583! Now, I suspect that if Tensorflow can handle it with x6 more weekly contributors than us and VScode x6 more weekly issues than us, we can probably too with a mono-repository. If it gets out of hand. We can break down the mono-repository later, once our scale forces it? But I don’t know if a single component will be responsible for a large flow issues. I suspect is will be a diffuse, in which case, how do we break it down? I wish this is a problem we will have to solve in the future, it would imply so much about our impact 😍.
4. Large effort potentially required to merge the sources. No pain no gain.

[eps1lon]

So it’s just point 3? Point 1, 2, 4 and 5 made by Olivier don’t apply? Has somebody looked at the viability of pulling in all the other tools? How do we merge it? What happens to history etc.

This seems all very shallow. “just merge it into packages/material-ui-pickers” is not enough. CI would probably slow down by 50%. Not to mention how this would even integrate regarding git history.

[dmtrKovalenko]

@eps1lon - I can do all the work of CI integration by myself. We do not need to merge stacks right now. I am thinking about speeding up CI by skipping parts if something not changed. If we will merge sources – our current documentation (material-ui-pickers.dev) can be deleted anyway, so we will not need to use Zeit now