You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Open index page in a browser (http://localhost:3000)
There is an error instead of correct view
Current behavior 😯
I use ESM and I want to import specific component from a folder to minimize a bundle size. Using ESM is confirmed by setting "type": "module" in package.json. I got an object, that contains some keys including default key instead of importing component itself. This leads to error on rendering React component so the imported object is not a component at all.
Expected behavior 🤔
I expect that if I write import Paper from '@mui/material/Paper';, there is a component in the Paper constant, not a weird object.
Context 🔦
The problem is that such an import is resolved to a CommonJS approach. It exports components using the exports keyword. Default export is specified as the default key with component as a value. And ESM cannot detect that it's a default export but not a default key of an exported object. Obvious solution is to try to specify all possible ways to export including the one which will be resolved by ESM import as a real default import. A good solution would be a resolving importing from ESM module to ESM modules placed in material package. It will work natively. There is a module path in a package.json that should help to resolve package correctly, but it does not work for some reason. Maybe it is necessary to add exports object to package.json. Also maybe it should be done in a root package.json, because ESM import looks into root package.json for all specific imports base on package name due to its specification.
P.S. And yes, there can not be a solution like removing type = module in the example. This problem is not unique for this example. It also can be reproduced if I am going to implement an ESM library with material-ui as a dependency.
There is an issue in which we discuss moving to ESM: #35233. I'll close this one as a duplicate, so we have one place for discussion. Feel free to comment in the other issue.
Duplicates
Latest version
Steps to reproduce 🕹
Link to live example:
I made a simple example repo: https://github.com/timbset/next-esm-example
Steps:
yarn dev
http://localhost:3000
)Current behavior 😯
I use ESM and I want to import specific component from a folder to minimize a bundle size. Using ESM is confirmed by setting
"type": "module"
inpackage.json
. I got an object, that contains some keys includingdefault
key instead of importing component itself. This leads to error on rendering React component so the imported object is not a component at all.Expected behavior 🤔
I expect that if I write
import Paper from '@mui/material/Paper';
, there is a component in the Paper constant, not a weird object.Context 🔦
The problem is that such an import is resolved to a CommonJS approach. It exports components using the
exports
keyword. Default export is specified as thedefault
key with component as a value. And ESM cannot detect that it's a default export but not adefault
key of an exported object. Obvious solution is to try to specify all possible ways to export including the one which will be resolved by ESM import as a real default import. A good solution would be a resolving importing from ESM module to ESM modules placed in material package. It will work natively. There is a module path in a package.json that should help to resolve package correctly, but it does not work for some reason. Maybe it is necessary to add exports object to package.json. Also maybe it should be done in a root package.json, because ESM import looks into root package.json for all specific imports base on package name due to its specification.P.S. And yes, there can not be a solution like removing
type = module
in the example. This problem is not unique for this example. It also can be reproduced if I am going to implement an ESM library with material-ui as a dependency.Your environment 🌎
npx @mui/envinfo
The text was updated successfully, but these errors were encountered: