Build as a multi-repository

[avocadowastaken]

Lot of us currently using stable version and it would be much easier to migrate each component separately.

So at the start we will be able to load components separately:

import { Card, CardText, CardActions } from 'material-ui';  // 0.19.0
import { Button } from "@material-ui/button"; // ^1.0.0

Idea from material-components.

Where user can install whole lib from material-components-web repo or each component separately from @material/*.

See lerna.

[oliviertassinari]

I have been giving some thought about this option in the past. I have even migrated one of my repositories to lerna. My conclusion was: it doesn't worth it for Material-UI.

Pros:

• Artificially increase the download stats on npm, good for bragging.
• Might help with the v0.x -> v1.x migration, but given both versions can easily be installed at the same time with yarn, I have some doubt
• Good for usage stats and component work prioritization 📈

Cons:

• Lose the shorter import option import { A, B, C } from 'material-ui' as a user. While it requires making sure tree shaking work, it's making the code more readable.
• Extra release complexity as a maintainer.

Other:

• Can allow splitting dependencies (I needed to split react & react-native for react-swipeable-views).

Unless I'm missing something, I haven't changed my mind yet.

[oliviertassinari]

Oh, and we already have some other packages:

• material-ui-icons
• material-ui-codemod
• eslint-plugin-material-ui

[avocadowastaken]

Lose the shorter import option import { A, B, C } from 'material-ui' as a user. While it requires making sure tree shaking work, it's making the code more readable.

Sorry I wasn't clear about this part.

Of course you should not remove material-ui repo itself, it just would be as another package that will reexport each component.

See [email protected]/index.js.

[oliviertassinari]

@umidbekkarimov Doesn't this index requires a more complex tree shaking solution?

Also, Lodash is doing something similar. I have never understood the motivation, I have always thought it was doing more harm than good to the community as increasing the module duplication likelihood for some unclear advantage. On the other hand, this seems to fit well for Babel needs.

[avocadowastaken]

Doesn't this index requires a more complex tree shaking solution?

Side note: This PR webpack/webpack#5435 will kill all Tree Shaking issues of material-ui, of course with few changes in index.es file. (rip babel-plugin-direct-import)

Lodash is doing something similar. I have never understood the motivation

I agree, it was overkill in case of lodash.

I have always thought it was doing more harm than good to the community as increasing the module duplication likelihood for some unclear advantage.

🤔 I only see the benefits in seamless migration to v1 (but as you said it can be done with yarn).

[oliviertassinari]

I'm closing the issue, as always in OSS a no is temporary. We will see if more voices are raised to go into this direction. Right now, I don't think that that change is worth the effort as a maintainer. I would rather see some other issues prioritized. Thanks for the discussion, it's a good seed 👍 .

[oliviertassinari]

I went back to this issue. It's haunting me. We are now releasing 5 different packages. They are hosted under the /packages folder. We have absorbed most of the maintenance overhead of such change. I have tried to perform critical thinking on this issue a second time. Again, I couldn't see this change being a win for us. How I see it 6 months later.

The pros:

• It's a safer feeling. You know you are not going to import 1 MB of JavaScript, no matter what. It provides a sense of scope safety.
• more ideas?

The cons:

• After [RFC] Should we flatten the folder structure? #9532, it would make the import path harder to get right. It would require more back and forth with the documentation.
• It's increasing the npm overhead, slower to download, more room for mistakes (more Degree of Freedom + Murphy's law). We will most likely move all the packages at once no matter what. It's what Babel do for the operational simplicity it provides.
• It's making the onboarding experience harder. You have installed one component and you are happy with it? Great, let's add another one! Oh, wait, an extra step. I need to npm install it.

[oliviertassinari]

That being said, #6218 could be a good candidate for multi-repository, to evaluate.