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

emit *.d.mts type files for esm entries #101

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

Sec-ant
Copy link

@Sec-ant Sec-ant commented Nov 2, 2022

Fix typescript module resolution issues when moduleResolution is set to node16 or nodenext in a module type package. Some discussions can be found here: pmndrs/zustand#1381 (comment)

Here is a minimal reproduction of this issue: https://stackblitz.com/edit/node-o5zatf?file=src/index.ts
and a patch-fixed version: https://stackblitz.com/edit/node-u9yq9u?file=src/index.ts (the linter is problematic but build result is good)

package.json Show resolved Hide resolved
@Caligatio
Copy link
Owner

Hi @Sec-ant! First off, thank you for taking the time to help with keeping up with the forever-changing Javascript/Typescript environment; this is probably my least favorite part of maintaining this project.

I would really like to avoid having the ship duplicate files if at all possible. Do you know if https://stackoverflow.com/a/72530967 would work?

@Sec-ant
Copy link
Author

Sec-ant commented Nov 3, 2022

Do you know if https://stackoverflow.com/a/72530967 would work?

I've tried this approach in the zustand repo and again I tested it in jssha and I'm afraid it won't work.

".": {
  "import": {
    "types": "./dist/sha.d.ts",
    "default": "./dist/sha.mjs"
  },
  "require": "./dist/sha.js"
},

image

Conditional exports indeed can explicitly set types and default to import, but import doesn't necessarily mean it is an ES module. If the imported package type file is not under a type: module scope or not named as *.d.mts, TSC will see it as a commonjs module type file, even if it is imported, and thus causing a mismatch.

I think the only way at the time being is to ship two sets of types for both cjs and es module entries.

@Caligatio
Copy link
Owner

Doh! Let me see if I can get rollup to do the right calls to produce .d.mts files. I realize that the .d.ts and .d.mts files can currently be the same thing but I'm sure something will cause issues in the future if I take shortcuts :)

This might take me a bit as we're imminently going to have a child and sleep deprivation + Javascript tooling is a bad combination.

@Sec-ant
Copy link
Author

Sec-ant commented Nov 4, 2022

Hey, no rush at all! Many congrats on the arrival of a new life and I wish you all the best!

I realize that the .d.ts and .d.mts files can currently be the same thing but I'm sure something will cause issues in the future if I take shortcuts :)

Yeah, they are actually not necessarily the same thing. If you have relative imports or exports in the source code, node ESM requires mandatory file extensions in those statements and typescript will leave them alone when compiling. So, the emitted declaration files can be different with those emitted by CJS modules. But in this case, for now, their contents are the same.

I can settle on my fork for the time being and I'll update here if I find some less patchy way to deal with this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants