[docs-infra] Fix import of cjs react-simple-code-editor in esm by brijeshb42 · Pull Request #48349 · mui/material-ui (original) (raw)
This is needed to make the package work correctly in mui-x.
Also -
- Updated the peer dep version requirement for base-ui to be 1 instead of whatever is used in the workspace
Involves the docs-infra product (https://www.notion.so/mui-org/b9f676062eb94747b6768209f7751305).
label
This is needed to make the package work correctly in mui-x
Is it possible to align bundler configurations such that the import can be consistent?
Is it possible to align bundler configurations such that the import can be consistent?
Not sure I understand. We maye be consuming all kinds of packages. One may have module.exports = Component and other might have exports.default = Component. Unless we bundle the libraries in our package build output, I dont think we can influence the build output from our just for some specific packages.
This would have worked fine if the library also had esm. I see that @oliviertassinari is maintainer of the package, so maybe its possible.
I see that @oliviertassinari is maintainer of the package, so maybe its possible.
I can publish changes indeed to react-simple-code-editor. But I think it depends on the plan to modernize live demo edits with @dav-is
I guess my point is, importing CJS from ESM is not uncommon and now supported under node.js. I'm just surprised we can't configure our docs bundlers to behave the same way. It's not like our bundles are shipping raw ESM to the browsers, so why isn't it possible to make it do synthetic default import for this case? And why is it happining on MUI X and not on material-ui? Is it because we're transpiling the package with Next.js on core repo?
I think we can live with this one-line hack till then.
Sure, but if it's a one-liner in a bundler configuration on the MUI X side that fixes it for all future cases, then I think I'd prefer that. Otherwise, yes, we can live with it.
Is it because we're transpiling the package with Next.js on core repo
Yes. mui core docs: next.config.ts aliases @mui/internal-core-docs → src/. Webpack rule runs babel on everything under workspace root. So the code gets compiled by babel with default interop which makes it work.
mui-x docs: consumes published @mui/internal-core-docs from node_modules. Next 15 externalizes node_modules packages for server bundle. That's why the build was failing on X during the page pre-rendering phase, with React's expected function but got object, that led me to find that this particular import was the issue.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mui-x docs: consumes published @mui/internal-core-docs from node_modules.
I suppose one solution then could be to compile in the synthetic default import with our build tooling then? Can it be whitelisted only for a specific package? Maybe that makes our build tooling harder to port?
I think its better to just patch the package on our side to also add module.exports = Component instead of bending our build tools to support this specific use case. Would have made sense if there were other similar packages.
Either that or this PR's change. Both work.
I already tried adding the package to next's transpilePackages list as well as adding the babel loader to work on this file. Both did not work for some reason.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})