[ROADMAP] Remove @material/core plan

[oliviertassinari]

I'm opening this pull-request so we can debate the change. Feedback welcomed!

What do you prefer between material-ui and @material-ui/core?

material-ui Pros:

• Simpler to type
• Better "marketing" by keeping the legacy name
• Keep the download stats

material-ui Cons:

• Less consistency with the other packages
• Makes the migration from v0.x. to v1 a bit harder
• Reset the download stats

[sakulstra]

Pros:

• simpler to type is no real argument imo - every modern ui performs autocomplete and if it's so much of a struggle you could even alias
• i wouldn't be sure if it's "better marketing" material-ui 1.x is pretty much a rewrite of material-ui as i get it - not just a new version which would be reflected by @material/core if form of a clean cut

I'd vote for consistency and easier migration/parallel usage, but I also get that the download stat problem is kind of sad :/

[fzaninotto]

I'm all for keeping the material-ui name, and removing the renaming from the plan.

• Small package names are a must. I, for one, don't have autocompletion enabled when typing imports.
• Removing this change makes 1.0 stable closer, and I think the absolute priority for mui should be to ship 1.0 ASAP.
• Scoped packages look weird IMO. I have always associated them with private registries. And I'm not the same: even though it was introduced more than 4 years ago, the scoped package syntax has failed to convince open-source authors beyond babel.
• The migration from 0.x is already hard enough, cf https://gist.github.com/fzaninotto/0a59220e0460134de321b415d1418e99
• Download stats are important

[rosskevin]

• scoped packages - usage of a scoped package is now a norm for me, and many large projects (not to mention private packages) are using scopes as it provides them their own unconflicted namespace. We already are publishing other scoped packages now under the org and this change provides for consistency.
• length - it is slightly longer but I don't believe problematic
• migration - migration to another major version is already involved. One more search and replace is not a big deal
• timing - It must be done before 1.0. Babel did it between 6 and 7.
• stats - We lose history but not a big deal. Our stats will be the reestablish quickly once we switch packages. Did babel fret over download history stats (serious question)? I think material-ui is anchored enough that we do not need to worry about loss of stats at this point. Stats are important in determining adoption but as anyone would see in new stats, we have a significant user base - and therefore it is worth looking at in any due diligence process.

I don't see strong counter arguments and I see this as a necessary growing pain. Keeping the current name provides inconsistency with the new scoped package names we are releasing.

Arguments for the change:

• consistency
• growth/open namespace
• remove and chance of confusing the plethora of unofficial packages with official scoped packages

I am in favor of the change to @material-ui/core pre-1.0 release.

[mbrookes]

I don't have a strong preference on the outcome but:

• I don't think "marketing" will be meaningfully affected.
• If four more characters is too much to type, time for a change of occupation!:
• Download stats is a vanity metric. We'll get over it.

Lets not forget the twitter survey:

https://twitter.com/olivtassinari/status/947161769528655888

Nearly 73% of those who know what a scoped package is were in favour, vs. 26% against.

Also the response to #9673 (which is predominantly regarding the scoped package) was overwhelmingly positive. Some of that is perhaps just general sentiment towards the subject "Let's ship v1!", but I have to assume a reasonable number actually read the comment and agreed.

Downsides?

Granted, the current naming looks cleaner / easier to read.
Another breaking change.
???

[pelotom]

The fact that YES < (NO + “what is a scoped package?”) in that poll should perhaps be of some concern to those advocating for the switch...

[mbrookes]

The fact that YES < (NO + “what is a scoped package?”) in that poll should perhaps be of some concern

Not really - you have to assume that those that don't know would favour / object to the proposal in roughly the same proportion as those that do, if they had the required knowledge to answer the question.

[kgregory]

Some thoughts:

I don't think material-ui is any more or less marketable because of how it is imported. As long as it serves the same purposes and meets the same needs, people will use this package whether we scope the core package or not.

Download stats may help a new user assess the viability of a package, but it will probably never be the sole metric. It really shouldn't. Along with does this thing work for me?, nearly all other metrics (like repo activity, team responsiveness, community involvement, issue resolution, exposure and reputation on various social and professional networks) will be unaffected by a reset of download stats.

Many StackOverflow answers, tutorials, and blog posts will be rendered out of date, but this is to be expected as libraries mature. As long as the docs are right, we'll be good. Any guide worth its salt should refer the reader to the source material. Plus, this change could be succinctly explained in one place in our documentation.

I know there have been concerns with typing extra characters, but it seems silly to me for a few reasons:

1. It isn't that much more typing
2. Hopefully this isn't a change anybody would make manually when converting an existing codebase
3. If material-ui was originally created with a slightly longer name, you'd probably still use it
4. Editors are designed to help with these supposed hardships. If you've chosen to prevent it from doing so, I don't know what to tell you other than you probably use packages with names longer than material-ui and deal with it currently.

I think it would be better to stay consistent with what we're already doing for our other packages. If you think scoped packages 'look weird', maybe you also think the inconsistency between importing an icon and a component is weird as well.

Compare this:

import Button from 'material-ui/Button';
import Icon from 'material-ui/Icon';
import AddIcon from '@material-ui/icons/Add';
import DeleteIcon from '@material-ui/icons/Delete';

To this:

import Button from '@material-ui/core/Button';
import Icon from '@material-ui/core/Icon';
import AddIcon from '@material-ui/icons/Add';
import DeleteIcon from '@material-ui/icons/Delete';

I would prefer a consistent approach to packages.

[sebald]

Personally I find scoped packages a really good think. The pros/cons are already noted by @kgregory and @rosskevin 🙂

[alitaheri]

If there is a chance to include third-party libraries in the mix, like material-ui-pickers then we'll have great consistency with @material-ui otherwise we'll run into more inconsistencies:

import Button from '@material-ui/core/Button';
import DatePicker from 'material-ui-pickers/DatePicker';

and there is absolutely no way for the third party authors to make this consistent with the core.

but if we plan on adding all third parties in to the org (if they wish) and release their packages under @material-ui then I think we'll have a good set of modules:

import Button from '@material-ui/core/Button';
import AddIcon from '@material-ui/icons/Add';
import DatePicker from '@material-ui/pickers/DatePicker';

[rosskevin]

We plan on adding third party libraries to the mui-org, but for the many packages, the general user base will notice the difference and I see that as a good thing. Users will know that the @material-ui packages are curated, whereas other packages will be up to them regarding due diligence.

As-is, a poorly maintained/unmaintained package can be prefixed with material-ui and confused as produced by the org. I suspect this was a significant factor in Babel's decision to use scoped packages.

[oliviertassinari]

Thanks for the feedback guys. Alright, it seems that people value the consistency over the other points:

1. Marketing: following @sakulstra's argument, @material-ui/core is a "rebranding". It better translate what happened between v0.x and v1: it's a rewrite. So, changing the package name might be good for marketing.
2. package name length. The relative difference is +54%. If it really starts to be an issue for people, they can configure an alias in their bundling config. For instance, they could be using mui, witch has a -72% relative different to material-ui and a -82% relative different to @material-ui/core.
3. A different package name will help in the migration from v0.x to v1. We can kill the material-ui-next package.
4. The package renaming will make all the documentation resources out-of-date (StackOverflow, GitHub issues, CodeSandbox, third-party tutorials).
   We can take advantage of it. Users will be able to know at first glace if the information they are reading is up-to-date or not. Isn't the code using the scoped package? Well, the odds are the code is not longer working anyway because of all the breaking changes. Is the code using a scoped package? Great! It's from the stable v1 release. People can follow it.

[alitaheri]

@rosskevin I see your point. I completely agree with you, didn't consider that aspect of it 😁

[TheMoonDawg]

After reading everyone's comments, definitely agree that the scoped package name is the way to go. It will give people a clearer understanding of what packages are "official" as well as figuring out which version is stable.

And as oliviertassinari said, if it bothers people THAT much, you can always just create an alias!

[fzaninotto]

if it bothers people THAT much, you can always just create an alias!

I'm interested, how can I create an alias? Note: I don't use webpack nor any other bundler.

[oliviertassinari]

@fzaninotto Personally, I'm using babel-plugin-module-resolver.

babelrc

{
  "plugins": [
    ["module-resolver", {
      "alias": {
        "mui": "@material-ui/core"
      }
    }]
  ]
}