-
-
Notifications
You must be signed in to change notification settings - Fork 47
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 (no import extensions variant) #821
Conversation
f9f04cd
to
417dc87
Compare
Netlify deploy preview |
417dc87
to
d6e7a86
Compare
I'd expected the result after running tsc-alias to be the same regardless of esm or cjs. isn't that the case if you used the same file extension for both? |
It does look the same in this case, yes (I don't know if that's true for any input, but I haven't found anything that could cause differences so far). I went the simpler way, not having to deal with copying build .d.ts files across directories, but since running |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The built package looks great
publint
is also happy apart from the typos I mentioned
Builds "true" ES modules alongside CommonJS output.
Summary of changes
/build/esm
/build/cjs
exports
field was added to the packagetypesVersion
field was added to package.json for compatibility with older tsconfig settingsType 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 theexports
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 (#827), this won't be a problem for long.
This is a variant of #745 that does not require file extensions in import/export specifiers. It uses
babel-plugin-add-import-extension
to modify JS files andtsc-alias
to modify type definitions.Closes #550
Closes #648