v0.20.0 Failed to compile - 'material-ui' does not contain an export named 'TableSortLabel'

[mikeriley131]

• I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

App should start without issue with MUI compiling properly.

Current Behavior

I get the following error after installing v0.20.0 and running npm start:

Failed to compile
./node_modules/@devexpress/dx-react-grid-material-ui/dist/dx-react-grid-material-ui.es.js
1071:4-18 'material-ui' does not contain an export named 'TableSortLabel'.

When l look in the node_modules folder, there is no TableSortLabel.js file in the Table folder. I do see it in the repo though (https://github.com/mui-org/material-ui/blob/v1-beta/src/Table/TableSortLabel.js).

Steps to Reproduce (for bugs)

1. npm uninstall material-ui
2. npm install material-ui@latest
3. Start your app (npm start, yarn start, etc.)
4. See the "Failed to Compile" error.

Context

Can not start app with lastest version of MUI.

Your Environment

Tech	Version
Material-UI	0.20.0
React	15.6.1
browser	all
etc

[mbrookes]

dx-react-grid-material-ui has a dependency on v1-beta, you're using v0.20.0.

[mikeriley131]

Ah, right. Any idea why I'm seeing the component in the repo but not in the node_modules folder?

[mbrookes]

v1-beta is the default branch since that's the focus for new development, v0.20.0 is on the master branch.

[oliviertassinari]

I have added the bug flag. The issue will be definitely solved once we use a different npm repository name for v1.

[oliviertassinari]

@mui-org/core-contributors I think that we will better off hosting v1 under a different npm package name. Hosing all the packages under an organization will:

• signal what's official and what's not.
• prevent future name clashing
• make the transition from v0.x to v1 much easier.
• provide simpler ACL handling.

Here are two alternatives I'm considering. I don't think people have weighted their preference yet:

import { Button } from '@material-ui/core';
import Icons from'@material-ui/icons';
import DatePicker from '@material-ui/date-picker';

import { Button } from '@mui-org/material-ui';
import Icons from'@mui-org/material-ui-icons';
import DatePicker from '@mui-org/material-ui-date-picker';

// More idea?

[rosskevin]

So we have the npm org material-ui just not the GitHub org correct?

[pelotom]

Purely from a usability standpoint, I favor keeping it all under material-ui as it is now, because it's easy to remember and less typing. But maybe that's just me 🤷‍♂️

[oliviertassinari]

So we have the npm org material-ui

@rosskevin We have: https://www.npmjs.com/org/material-ui and https://www.npmjs.com/org/mui-org

[rosskevin]

I like option 1 from a usage standpoint, but it will be confusing if the org and/or repo names don't match.

e.g. core package to material-ui repo?

It are we going to rename the repo as well?

[hai-cea]

We currently have https://www.npmjs.com/package/material-ui-next which some are using. I think it would be nice if we could keep the material-ui npm registry after v1 moves out of beta. Essentially, when the v1-beta branch becomes master.

[leMaik]

@oliviertassinari I like option 1. 👍 It would be nice to have many material-ui related packages (more components) available at @material-ui/some-wild-component. I don't think that it will be confusing that thre orgs don't match. Actually, @mui-org/material-ui-some-wild-component is pretty redundant and long. It confuses me that this org is called mui-org instead of material-ui.

[hai-cea]

It confuses me that this org is called mui-org instead of material-ui.

@leMaik Yeh, I wish we could have gotten the material-ui organization name. But, unfortunately, it was taken.

[oliviertassinari]

I also like option 1. better.

I think it would be nice if we could keep the material-ui npm registry after v1 moves out of beta. Essentially, when the v1-beta branch becomes master.

@hai-cea What about the 4 advantages of moving to an organization package name?

[oliviertassinari]

@hai-cea For instance, we will be able to revert #8473 by using a different npm repository name (-1933 LOCs). It's just the tip of the iceberg.

[hai-cea]

@oliviertassinari Yeh, I agree with what you're saying. I'm just thinking there's an advantage to material-ui going from v0.x to v1.0.0 on the same package. It would signal an official release and a big milestone for the project. At that point, support for v0.x can stop and the v1-beta branch becomes master and all the download stats will be intact.

I think it makes total sense what you're saying. I'm just wondering if we want to make the separate package temporary?

[hai-cea]

It would be nice to have many material-ui related packages (more components) available at @material-ui/some-wild-component.

An alternative to this would be to prefix all material-ui packages with mui.

• mui-core
• mui-icons
• mui-date-picker

This is similar to React - https://github.com/facebook/react/tree/master/packages

[oliviertassinari]

I'm just wondering if we want to make the separate package temporary?

@hai-cea Does it mean you want to ask external lib authors to change the dependency from material-ui to material-ui-next while it's not stable, then asking them to move back to material-ui?
What if people are waiting for the stable release to start the migration?

It's really tricky as some external libs might be relying on [email protected] while others on [email protected]. In this situation people can't have both versions installed at the same time.
They only have one option. They do the migration in one go. In that case. I would rather not changing anything.

Regarding, signaling what's official or not, provide simpler ACL handling and prevent future name clashing. It won't be an issue if we keep the mono-package approach or don't host new packages.

[oliviertassinari]

Ok, as far as I'm concern. We can close this issue and defer the package name change to an ulterior moment. A point where we feel an better pain. This moment might never come. I have opened an issue to keep track of the 1993 LOCs #9469.

[hai-cea]

It's really tricky as some external libs might be relying on [email protected] while others on [email protected]. In this situation people can't have both versions installed at the same time.

@oliviertassinari Ah yeh, that's a really good point. I agree with you that keeping material-ui is problematic.

[oliviertassinari]

@mui-org/core-contributors I don't think that we have reached a consensus. The current answer to the migration problem if you rely on external libraries is: "port everything in one go". I still think that @material-ui/core package naming offers good potential. Feel free to weight your point of view.

I'm closing the issue as I have been hijacking it. @mikeriley131 Sorry 😬 .
The README.md has been updated. The v0.x/v1.x should be clearer now:

[rosskevin]

Strong +1 on @material-ui/core. Scalable namespace.