Material-ui: Classname mismatch depending on 'from' component import

[lucasavila00]

I'm having this bug after updating everything

    "@material-ui/core": "^4.3.2",
    "@material-ui/icons": "^4.2.1",
    "@material-ui/lab": "^4.0.0-alpha.23",
    "@material-ui/styles": "^4.3.0",

and I have a very complicated build that I could not simplify to debug the error properly but I found something interesting.

if I import Typography like this it errors:

import Typography from "@material-ui/core/Typography/Typography";

But like this:

import { Typography } from "@material-ui/core";
or
import Typography from "@material-ui/core/Typography";

I got no errors...

I don't know why it is exported at both these locations and why shouldn't I use the first one.
I was only using this specific way of importing because vscode suggested it like it.
If this is wrong I guess we should let people know

--- Edit

Not only Typography but any* component imported like this will cause the same issue.
*I tested with Button, Typography, CardContent, CardAction

Here is a gist with a script to catch this kinds of import in your code
https://gist.github.com/lucasavila00/0291e437ae237f902b1213a9aa0c5cb8

[merceyz]

See https://material-ui.com/guides/minimizing-bundle-size/ for answers to some of your questions but to summarize the relevant parts

For convenience, Material-UI exposes its full API on the top-level material-ui import. If you're using ES6 modules and a bundler that supports tree-shaking (webpack >= 2.x, parcel with a flag) you can safely use named imports and expect only a minimal set of Material-UI components in your bundle
[...]
Be aware that tree-shaking is an optimization that is usually only applied to production bundles. Development bundles will contain the full library which can lead to slower startup times.
[...]
Be aware that we only support first and second level imports. Anything below is considered private and can cause module duplication in your bundle.

[lookfirst]

@merceyz There is nothing 'convenient' about a broken build or extremely confusing behavior because of imports. In reality, it creates a lot of bugs and wasted developer time. Let's focus on picking a single modern method and making everyone conform to that.

[lucasavila00]

@lookfirst I completely agree with you.
I got into this issue because I trusted the IDE auto import, and I think a lot of people do it aswell.
This wasn't an issue on V2 and it became on V4 and nowhere on the migration docs it was explained.
I believe IDE support is really important and this kind of issues should be solved.
And I'm here to help with the needed code changes :)

[joshwooding]

I use Webstorm and I seem to get the correct suggested imports :/ I’ll play around later to investigate some more.

[lookfirst]

MUI 4.3.2
Typescript 3.5.3

IntelliJ IDEA 2019.2.1 (Ultimate Edition)
Build #IU-192.6262.41, built on August 15, 2019
Subscription is active until March 1, 2020
For non-commercial open source development only.
Runtime version: 11.0.3+12-b304.39 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.14.6
GC: G1 Young Generation, G1 Old Generation
Memory: 2048M
Cores: 12
Registry: debugger.watches.in.variables=false
Non-Bundled Plugins: GrepConsole, Lombook Plugin, com.dubreuia, com.intellij.plugins.watcher, name.kropp.intellij.makefile, AutoPackage, org.intellij.plugins.hcl, org.jetbrains.plugins.go-template, com.intellij.lang.jsgraphql, com.intellij.react.css.modules, com.wix.eslint, intellij.prettierJS, org.jetbrains.plugins.go, Dart, io.flutter, izhangzhihao.rainbow.brackets, Pythonid, org.jetbrains.plugins.ruby, org.toml.lang, ru.adelf.idea.dotenv, ua.in.dej.myEmmet

I literally just copy/pasted this bit into a new Foo.tsx file and the imports you see in the image are what was automatically created.

const useCommonStyles = makeStyles((theme: Theme) =>
    createStyles({
        mainContent: {
            flex: 1,
            padding: '48px 36px 0',
            background: '#eaeff1',
        },
    }),
);

export function MainWithView() {
    const classes = useCommonStyles();

    return (
        <main className={classes.mainContent}>
            <NotFoundBoundary render={NotFoundComponent}>
                <View/>
            </NotFoundBoundary>
        </main>
    );
}

This is the error I see when I restart CRA.

/admin/src/layout/Foo.tsx
TypeScript error in /admin/src/layout/Foo.tsx(1,1):
All files must be modules when the '--isolatedModules' flag is provided.  TS1208

Which makes me think it is my tsconfig... yep, it is. But this is default CRA settings...

{
  "compilerOptions": {
    "target": "es5",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowSyntheticDefaultImports": true,
    "checkJs": false,
    "allowJs": false,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "strict": true,
    "noImplicitReturns": true,
    "forceConsistentCasingInFileNames": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react",
    "baseUrl": "src",
    "rootDirs": [
      "src",
      "test",
      "stories"
    ]
  },
  "include": [
    "src",
    "test",
    "stories"
  ],
  "exclude": [
    "node_modules",
    "build"
  ]
}

Note that I get that error likely because I've also implemented babel-transform-imports per the instructions (which I wrote) on the MUI website.

[merceyz]

The @material-ui/core imports in that image are correct.

I've also implemented babel-transform-imports per the instructions (which I wrote) on the MUI website.

A solution for babel-transform-imports not handling the styles folder correctly is here https://github.com/mui-org/material-ui/pull/17015

[lookfirst]

The @material-ui/core imports in that image are correct.

Not currently. But, I see your addition in #17015. If that works, then once it is in, I think this can be closed after the documentation is updated. But really, we're still a mess of imports. Your fixes just make things magically work a bit better at the expense of a lot of underlying complicated code.

[merceyz]

Not currently

Please elaborate

[lookfirst]

From my comment above, I give the error message I get when starting CRA using those imports.

[oliviertassinari]

import Typography from "@material-ui/core/Typography/Typography";

⚠️ This is a private module, don't import it! We have an eslint rule to mitigate the issue in this codebase: https://github.com/mui-org/material-ui/blob/master/packages/eslint-plugin-material-ui/README.md#restricted-path-imports. We could consider to publish it. However, I doubt that it will gain much adoption, at least, only to people that are hit by the problem.

I can't think of any good solution to this problem. Should we ignore it and live with it?

[merceyz]

@lookfirst Your issue is unrelated to this one, the imports are valid. You can open a issue with a reproducible example if the issue persists

Should we ignore it and live with it?

@oliviertassinari :+1:

[lookfirst]

@merceyz Your attitude is extremely dismissive. The imports may be 'valid' in your eyes, but they break when used in combination with existing documentation. There is quite a few people with confusion about this issue. I have filed an issue. #17030

[merceyz]

Your attitude is extremely dismissive

I'm not trying to dismiss your issue, i'm trying to help you. But your issue is unrelated to this one, which is why I said [...] open a issue with a reproducible example [...].

In https://github.com/mui-org/material-ui/issues/17038#issuecomment-522491357 I asked you to elaborate on why the imports are invalid and causing issues for you, but you didn't. Instead you pointed back to one of your previous comments which didn't have enough information, which is why I asked for more information.

Based on the information you provided in https://github.com/mui-org/material-ui/issues/17038#issuecomment-522326757 and with the complaint of "invalid imports" there isn't more that can be done without a reproducible example showcasing these imports causing errors (codesandbox etc).

The imports may be 'valid' in your eyes

The documentation say they are valid, testing with the information provided in https://github.com/mui-org/material-ui/issues/17038#issuecomment-522326757, they are valid, what I think is irrelevant.

but they break when used in combination with existing documentation

Open a issue showcasing this and provide a reproducible example(https://stackoverflow.com/help/minimal-reproducible-example) so we can help you.

[lookfirst]

but you didn't

Yes. I did. Scroll up.

[merceyz]

Yes. I did. Scroll up.

The next sentence adressed that response.

Instead you pointed back to one of your previous comments which didn't have enough information, which is why I asked for more information.

[oliviertassinari]

@merceyz There is one approach that could help, but I'm not sure how much practice it would be. What if we were generating a flat bundle for each subfolder?

[lookfirst]

@merceyz No, you didn't ask for more information. You didn't tell me what was missing or give me any input on how trying what I gave you caused you any sort of confusion. You totally ignored the fact that I gave you an error message. You did nothing to try to reproduce the issue that I detailed.

Now you've just pointed me at a stupid SO article as if I'm some newbie developer. Good job, I'm done.

[oliviertassinari]

To expand on https://github.com/mui-org/material-ui/issues/17038#issuecomment-523513981, the idea was to have this folder structure in the published package:

├── @material-ui/core/Typography/
│ ├── index.js
│ ├── index.d.ts
│ ├── package.json

instead of https://unpkg.com/browse/@material-ui/core@4.3.3/Typography/

[merceyz]

It would be possible to use rollup to combine everything in each folder to a index.js file and leave the esm output as it currently is so it wont hurt tree shaking.

Don't think the same is possible for *.d.ts files

/ cc @eps1lon