Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[core] Add exports field and build proper ES modules #745

Closed
wants to merge 19 commits into from

Conversation

michaldudak
Copy link
Member

@michaldudak michaldudak commented Oct 18, 2024

Builds "true" ES modules alongside CommonJS output.

Summary of changes

  • ESM build output is placed under /build/esm
  • CommonJS build output is placed under /build/cjs
  • Per-component package.json files were removed
  • The exports field was added to the package
  • The typesVersion field was added to package.json for compatibility with older tsconfig settings
  • Type definitions are built per target - the CJS one with module: "nodenext", the other one with module: "esnext".
  • Are The Types Wrong CLI is executed on CI to check if no issues with the package are introduced.

Type definitions

To verify if different methods of module resolution in TypeScript can resolve the exported types, the Are The Types Wrong (ATTW) tool was used. Its reports led to building the type definitions per build output (to avoid errors like False CJS and False ESM.
Another reported issue was the inability to resolve types under the node10 module resolution when the exports field is used. While we don't support Node 10, Typescript uses this resolution strategy by default (see https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/NoResolution.md#false-positive-unsupported-file-extension).
To work around this, I introduced the typesVersions field in package.json, as described in https://github.com/andrewbranch/example-subpath-exports-ts-compat/tree/main/examples/node_modules/types-versions-wildcards.

Testing

I created a repo to test the package with different bundlers and plain Node.js: https://github.com/michaldudak/base-ui-bundler-tests. There is an issue with running a Node.js app in ESM mode due to Base UI dependency on @mui/utils. The utils package does not currently conform to the ESM spec and cannot be used without a bundler this way.
As we're planning to move away from it and define our utilities locally, this won't be a problem for long.


This is built on top of #812

@michaldudak michaldudak added the core Infrastructure work going on behind the scenes label Oct 18, 2024
@mui-bot
Copy link

mui-bot commented Oct 18, 2024

Netlify deploy preview

https://deploy-preview-745--base-ui.netlify.app/

Generated by 🚫 dangerJS against f372410

@github-actions github-actions bot added PR: out-of-date The pull request has merge conflicts and can't be merged and removed PR: out-of-date The pull request has merge conflicts and can't be merged labels Nov 1, 2024
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Nov 12, 2024
@michaldudak michaldudak requested a review from a team November 12, 2024 19:17
@michaldudak michaldudak marked this pull request as ready for review November 13, 2024 10:36
@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Nov 14, 2024
@michaldudak michaldudak marked this pull request as draft November 15, 2024 09:52
@michaldudak
Copy link
Member Author

Superseded by #821

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Infrastructure work going on behind the scenes PR: out-of-date The pull request has merge conflicts and can't be merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants