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

listFiles[Only] does not list upstream package.json files whose exports were used for path resolution #60629

Open
ddurschlag opened this issue Nov 27, 2024 · 4 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@ddurschlag
Copy link

🔎 Search Terms

listFiles listFilesOnly package.json exports

🕗 Version & Regression Information

  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about listFiles

I tried 3.9.5 which also doesn't list the upstream package.json (though it actually doesn't list the .d.ts file either, so that's even worse).

⏯ Playground Link

https://github.com/ddurschlag/typescript-listFiles-demo/

💻 Code

When doing a bare import:

import { sayHello } from 'upstream';

...if the upstream module's exports are specified in the package.json:

  "exports": {
    ".": "./dist/specific_name.js",
    "./*": "./dist/*"
  }

tsc's listFiles and listFilesOnly features do not list this package.json. This is problematic for, e.g., detecting if the project has changed such that a rebuild may be required.

🙁 Actual behavior

Upstream package.json was not listed in the file output.

🙂 Expected behavior

Upstream package.json is listed in the file output.

Additional information about the issue

No response

@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Nov 27, 2024

listFiles shows the source files we'd use for compilation, not the complete list of files on disk we consulted. A correct list for detecting rebuilds would be much be longer than just including package.json files -- it'd include many probes for non-existing files, etc..

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Nov 27, 2024
@ddurschlag
Copy link
Author

So is there any way to get a list of files whose update should trigger a rebuild, @RyanCavanaugh ? Let's say, to make it easier, I'm ok with not including "files that could force a rebuild by coming into existence," since I understand that list could potentially be extremely lengthy.

@RyanCavanaugh
Copy link
Member

There isn't a user-facing way to get that info. You'd need to use the compiler API and provide a file system host to intercept the I/O calls to see what parts of the fs are being looked at.

@Andarist
Copy link
Contributor

I'm not sure what's the OP's use case but maybe --traceResolution could be used for this. By scanning its output you could learn about every file used to determine the resolution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

3 participants