There is a compatibility issue with "moduleResolution": "NodeNext" in TS

[0xDing]

Describe the bug
Codemirror does not compile with typescript 4.8 when "module": "ESNext" and "moduleResolution": "NodeNext" in the tsconfig. Error:

error TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("ts-pattern")' call instead.

In a few words, TS introduced new ways to publish and consume type definitions and TS files depending on if you code using ESM or Commonjs.

• I believe the change was announced here * More actionable background here.

According to this, adding an index.d.cts does the trick. So I copy-pasted the index.d.ts and renamed it. Then I removed types from the package.json and it did not work.

Versions

• TypeScript version: 4.8.2
• ts-pattern version: 4.0.4
• environment: browser + version / node version / deno version

[rawnly]

Same here, would love to find a solution 👀

[gvergnaud]

Hey! Could you provide a link to a project/repo reproducing the issue so I can take a look?

[0xDing]

Hey! Could you provide a link to a project/repo reproducing the issue so I can take a look?

https://github.com/0xDing/ts-pattern-issue-110

[patroza]

For me types imported from index.d.ts don't work at all in my project.
The workaround is to remove "type": "module" from the package.json.

Otherwise, the imports inside d.ts that is specified in the import: { types section of package.json must include .js module qualifiers, but I'd imagine that breaks types for cjs users.
So either seems to need to drop the type: module, or generate separate d.ts for import vs require.

Related change: #89

[tgillus]

For me types imported from index.d.ts don't work at all in my project. The workaround is to remove "type": "module" from the package.json.

Otherwise, the imports inside d.ts that is specified in the import: { types section of package.json must include .js module qualifiers, but I'd imagine that breaks types for cjs users. So either seems to need to drop the type: module, or generate separate d.ts for import vs require.

Related change: #89

Has anyone found a workaround for this issue (that doesn't require reverting back to CommonJS or modifying content within the node_modules directory)? I've been using ts-pattern 3.3.5 in order to maintain the ability to have type information (and code completion) available while coding in VSCode.

[gvergnaud]

I tried updating ts-pattern's package.json to follow microbundle's recommendation to support NodeNext, but it doesn't seem to be working when cloning this test repo...

Here is the PR if somebody wants to take a look: #136

The updated version is published as ts-pattern@test

[rhyek]

Getting anys everywhere with ts-pattern@test.

Hoping for a fix soon.

[jeffwad]

We've encountered the same issue working with the latest version using .mts in VSCode. However, one of my colleagues uses Webstorm, in which it works correctly. See screenshot of the match function showing it's type signature.

I don't know if this is of help - but thought you should know.

[Darkle]

Typescript 5 was just released and has a new moduleResolution setting of 'bundler' which seems to fix this issue (at least for me).

https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#moduleresolution-bundler

[elnygren]

Using moduleResolution: 'bundler' is not a fix, it just silences the issue by having a more relaxed module resolution checking. It should only be used if actually using a bundler (like webpack, esbuild, vite...).

This project's typings are broken if using moduleResolution: NodeNext which is the normal moduleResolution to use if writing modern node.js with ESM ("type": "module" in package.json)

[mjsampson]

USE AT YOUR OWN RISK: I've barely tested and only sort of know what I'm doing. I wouldn't be surprised if something is wonky but all I did was change the import paths and updated some of the tsconfig.json and package.json

For anyone dealing with this who wants a hacky solution they can just install and move on from, you can use the git repo below

https://github.com/mjsampson/ts-pattern-nodenext

To install add "ts-pattern": "git+https://github.com/mjsampson/ts-pattern-nodenext" to your package.json

The only things I did were

1. Update the tsconfig.json to use esnext and nodenext (this may not be necessary, I'm a bit of a typescript novice but its what I've been doing from my local libraries)
2. Update all the path imports to have .js extensions (I believe this is what did the trick and what @gvergnaud PR was missing)
3. remove the prepublish step from package.json because I didn't have time to mess around with getting the tests to work and I'm assuming the changes I made didn't break anything since it's just import paths and module resolution. I also and added a prepare script so that the install from github will build

I'm curious what's blocking ts-pattern from implementing this change completely, my naive guess is the library is tied to jest which makes full esm migration more tricky?

it builds and runs in staging for me, I've committed to esm modules with my codebase so if I hit another hitch with ts-pattern I'm just gonna have to find a replacement unless this issue gets resolved, but so far this is allowing me to use it with nodenext module resolution

edit: fixed some grammar

[viell-dev]

Checks against arethetypeswrong:

• v4.2.2: https://arethetypeswrong.github.io/?p=ts-pattern%404.2.2
• v4.1.4-test.0: https://arethetypeswrong.github.io/?p=ts-pattern%404.1.4-test.0

Whatever was changed in the test release is better but not perfect.

[gvergnaud]

After many iterations, I think I finally have a version that works with nodenext + commonjs modules: #160

https://arethetypeswrong.github.io/?p=ts-pattern%404.2.4-test.1

I tested it locally and it seems to be working, but It would be very helpful if you could try to install ts-pattern@4.2.4-test.1 in your nodenext + commonjs project, and let me know if everything works as expected!