importing own package from test fails with error TS5055: Cannot write file

[Gozala]

Bug Report

I had been running into #14538 and turns out it is caused by the fact that my test files import the package by it's name (as opposed to relative path). Which as far as I can tell causes TS to look into exports of the package.json which in my case looks like

"exports": {
    ".": {
      "types": "./dist/src/lib.d.ts",
      "import": "./src/lib.js"
    }
  }

Which in turn confuses compiler into trying to compile dist/src/lib.d.ts file even though dist is listed under exclude of the tsconfig.json.

Here is the CI flow that was failing illustrating the problem. and exact git revision

Changing import in the test to use relative impart path fixes the problem, however that is an unfortunate limitation.

🔎 Search Terms

• TS5055: Cannot write file

🕗 Version & Regression Information

This is a first time I'm able to try "moduleResolution": "nodenext" and is the issue I'm encountering.

💻 Code

https://github.com/web3-storage/data-segment/tree/047ea5120de095ff60a4df00698b4736fcaf2cc5

🙁 Actual behavior

As you can see in CI flow output

Using local typescript@5.0.4
Error: Cannot write file '/home/runner/work/data-segment/data-segment/dist/src/api.d.ts' because it would overwrite input file.
Error: Cannot write file '/home/runner/work/data-segment/data-segment/dist/src/lib.d.ts' because it would overwrite input file.
Error: Cannot write file '/home/runner/work/data-segment/data-segment/dist/src/merkletree.api.d.ts' because it would overwrite input file.
Error: Cannot write file '/home/runner/work/data-segment/data-segment/dist/src/node.d.ts' because it would overwrite input file.
Error: Cannot write file '/home/runner/work/data-segment/data-segment/dist/src/proof.d.ts' because it would overwrite input file.
Error: Found 5 errors!

🙂 Expected behavior

tsc --bulid should pass without any errors.

[RyanCavanaugh]

Which, in turn, confuses the compiler into trying to compile the dist/src/lib.d.ts file, even though dist is listed under exclude in the tsconfig.json.

excludeing files in the tsconfig.json does not affect module resolution, so there is at least one misunderstanding here. Additionally, the error about a file trying to be overwritten could only happen if a non-.d.ts file was added to the project, so that does not fit the description either.

Absent a more concrete argument about what is supposed to happen differently during which step of module resolution, this sounds like a misconfiguration

[Gozala]

@RyanCavanaugh the problem is that conventional node setup can not be configured. If there is a way to do it please let me know and I'm even happy to contribute doc improvements so it is covered.

In short I do not believe there is a way to import modules by package name inside the package itself, while also providing typedefs to package users. That is because:

1. If I leave out "types": "./dist/src/lib.d.ts", in the export map, users of the package will not discover any types provided by the library.
2. If I do put "types": "./dist/src/lib.d.ts" in the export map then importing module by package name fro the package causes typescript to resolve the typedef, which in turn causes it to complain about overwrite.

Absent a more concrete argument about what is supposed to happen differently during which step of module resolution, this sounds like a misconfiguration

Concrete expectation is that typescript will be able to recognize that module is imported from the package itself and will not therefor attempt to compile own typedefs over. Even better if it will be smart enough to resolve actual source as opposed to typedef.

[Gozala]

Also I might be missing something but why would TS even try to compile any .d.ts files ? Seems like they should be left alone as they are typedefs anyway

[Gozala]

Only workaround I was able to find is to add a paths directive into the tsconfig.json that maps itself to source dir

In the linked example it looks as follows

"paths": {
  "@web3-storage/data-segment": ["./src/lib.js"]
}

It is not ideal, but at least it works

[andrewbranch]

Minimal repro: https://github.com/andrewbranch/js-self-name-import

This looks like #47925 is just not quite doing its job for a JS project with --declaration