Mixing component import syntax breaks components in version 4.12.0

[CodeDead]

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

Lots of issues when mixing different import statement syntax in the latest release (4.12.0).

For example, when importing components using the import { component } from '@material-ui/core' syntax, and importing another component (for example a Table) using import Table from '@material-ui/core/Table' and setting the stickyHeader property to true on a Table component should make the table header.. well, sticky but it doesn't!

Expected Behavior 🤔

Setting the stickyHeader property to true on a Table component should make the table header sticky.

Setting a property on a component should work properly, regardless of the import statement syntax.

Steps to Reproduce 🕹

Steps:

1. Import most components using the import { component } from '@material-ui/core'; syntax;
2. Import a single component fully qualified: import Table from '@material-ui/core/Table';
3. Watch things break

Example using Table, TableCell, TableBody, TableHead and TableRow components, setting the stickyHeader property to true on the Table component and it not working at all:
https://codesandbox.io/s/sweet-water-gjq15?file=/src/App.js

Things are breaking if you inspect the table cells, having wrong classes in relation to the properties that are set on the Table component.

Here's how to make it 'work' as intended:
https://codesandbox.io/s/ecstatic-smoke-q2vz0?file=/src/App.js

There's only a singular difference between the two examples: the import statement.

Context 🔦

Importing components one way or the other is generally something the IDE does for you, and since this is mostly automatic, sometimes the different import styles are mixed, and as such, with the latest version of MUI, you get lots and lots of issues when running your application. This issue is not exclusive to the Table component. From my limited testing, this issue also applies to Select components for example and I'm sure many more.

Your Environment 🌎

  System:
    OS: Linux 5.12 Fedora 34 (Workstation Edition) 34 (Workstation Edition)
  Binaries:
    Node: 14.17.0 - /usr/bin/node
    Yarn: 2.4.2 - /usr/local/bin/yarn
    npm: 7.19.1 - /usr/local/bin/npm
  Browsers:
    Chrome: Not Found
    Firefox: 89.0.2
  npmPackages:
    @material-ui/core: ^y => 4.12.0 
    @material-ui/icons: ^4.11.2 => 4.11.2 
    @material-ui/styles:  4.11.4 
    @material-ui/system:  4.12.0 
    @material-ui/types:  5.1.0 
    @material-ui/utils:  4.11.2 
    @types/react:  17.0.13 
    react: ^17.0.2 => 17.0.2 
    react-dom: ^17.0.2 => 17.0.2 

[degitgitagitya]

Same here, using Next JS. The production build seems fine tho.

[mceIdo]

Same here.
Was this intentional? Why the breaking change on a minor?

[ddolcimascolo]

See #27149 Production builds are broken, too. @mui any update on this ?

[jagadeesh93]

Yes my production builds are also breaking any update on this issue ? @mui

[oliviertassinari]

It looks like the same issue as in #24206 (v5). The generated paths are wrong when we build with Windows:

https://unpkg.com/browse/@material-ui/[email protected]/Accordion/package.json

{
 "sideEffects": false,
 "module": "..\\esm\\Accordion\\index.js",
 "typings": "./index.d.ts"
}

vs.

https://unpkg.com/browse/@material-ui/[email protected]/Accordion/package.json

{
  "sideEffects": false,
  "module": "../esm/Accordion/index.js",
  "typings": "./index.d.ts"
}

As similar fix to #24223 should do it.

[mnajdova]

It's fixed in v4.12.1. Prove - https://codesandbox.io/s/gallant-http-khu11?file=/src/App.js Thanks for reporting and helping out debug the issue.