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

[mikeriley131]

• [x] 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:

1.

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

2.

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

3.

// 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. :+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.