Skip to content

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

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

Closed
Gozala opened this issue May 17, 2023 · 5 comments · Fixed by #54819
Closed

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

Gozala opened this issue May 17, 2023 · 5 comments · Fixed by #54819
Assignees
Labels
Fix Available A PR has been opened for this issue Needs Investigation This issue needs a team member to investigate its status.

Comments

@Gozala
Copy link

Gozala commented May 17, 2023

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 RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label May 23, 2023
@RyanCavanaugh
Copy link
Member

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
Copy link
Author

Gozala commented May 25, 2023

@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 Gozala changed the title importing package from test fails with error TS5055: Cannot write file importing own package from test fails with error TS5055: Cannot write file May 25, 2023
@Gozala
Copy link
Author

Gozala commented May 25, 2023

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
Copy link
Author

Gozala commented May 25, 2023

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

@RyanCavanaugh RyanCavanaugh added Needs Investigation This issue needs a team member to investigate its status. and removed Working as Intended The behavior described is the intended behavior; this is not a bug labels May 26, 2023
@RyanCavanaugh RyanCavanaugh added this to the TypeScript 5.2.0 milestone May 26, 2023
@andrewbranch
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fix Available A PR has been opened for this issue Needs Investigation This issue needs a team member to investigate its status.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants