TypeScript source files in "types" exports can cause compilation errors (npm)

[frangio]

In #377 the package.json files for npm where changed so that the source .ts files are used for "types" exports instead of .d.ts files as was done previously. This is not right, because when such a package is installed and imported in a TypeScript file, TypeScript will try to compile the dependency source file with the project's compilation settings, which may be different and cause compilation errors, for example, due to different settings for noUncheckedIndexedAccess.

The original issue #313 that was marked as fixed proposed adding declaration maps and source files in addition to the compiled .d.ts files that go in "types" exports. This allows "go to definition" to work as expected, and does not cause the compilation errors that the current approach causes.

[lucacasonato]

Oh this is not intentional - do you have an example where this is happening? It should not point to .ts files ever 😓

[frangio]

I noticed it when installing the package @noble/secp256k1.

The contents of https://npm.jsr.io/~/8/@jsr/noble__secp256k1/2.1.0.tgz are:

package/LICENSE
package/README.md
package/index.js
package/index.ts
package/jsr.json
package/package.json

and package.json looks like this:

{
  "name": "@jsr/noble__secp256k1",
  "version": "2.1.0",
  "homepage": "https://jsr.io/@noble/secp256k1",
  "type": "module",
  "dependencies": {},
  "exports": {
    ".": {
      "types": "./index.ts",
      "default": "./index.js"
    }
  },
  "_jsr_revision": 8
}

[alexgleason]

Wow, this explains a lot! I have been fighting with this issue for several days. Source files of JSR packages are getting type-checked.

AbortSignal.any is not available in vanilla TypeScript (even though browsers support it). And my client code in Node is getting type errors from the package implementation instead of just caring about the signatures.

[lucacasonato]

Great - thanks. I'll get this fixed today

[lucacasonato]

I can reproduce - this happens for packages that are using slow types, so where no d.ts file is emitted.

[alexgleason]

I'm still struggling with it. Not sure if it's my fault. The package does not have slow types.

In node_modules/@nostrify/nostrify I have NPool.ts, NPool.js, and NPool.d.ts.

If I delete NPool.ts manually then it works fine.

My bundler (Vite) is trying to load the .ts source file for some reason.

[lucacasonato]

It will be working tomorrow - there is one more PR that needs to land (#463), and then all the tarballs will be regenerated in the background over the course of tomomrrow - I'll let you know once it's actually fixed in prod :)

[lucacasonato]

@alexgleason This is now fixed. Remove your lockfile and re-run npm i to get an updated node_modules/ folder.

[alexgleason]

It works now. Thank you @lucacasonato !! 🚀