[docs-infra] Fix import of cjs react-simple-code-editor in esm

[brijeshb42]

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

[code-infra-dashboard]

Bundle size

Bundle	Parsed size	Gzip size
@mui/material	0B(0.00%)	0B(0.00%)
@mui/lab	0B(0.00%)	0B(0.00%)
@mui/private-theming	0B(0.00%)	0B(0.00%)
@mui/system	0B(0.00%)	0B(0.00%)
@mui/utils	0B(0.00%)	0B(0.00%)

Details of bundle changes

Deploy preview

https://deploy-preview-48349--material-ui.netlify.app/

---

Check out the code infra dashboard for more information about this PR.

[Janpot]

Is it possible to align bundler configurations such that the import can be consistent?

[brijeshb42]

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.

[oliviertassinari]

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

[brijeshb42]

I think we can live with this one-line hack till then.

[Janpot]

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.

[brijeshb42]

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.

[Janpot]

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?

[brijeshb42]

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.