Watch failed lookups, affecting locations only if resolution was failed

[sheetalkamat]

This is the most aggressive version : 3 types of tests failure

1. edits to package.json are ignored - most scenarios these edits will be watched for files's mode
2. alternate js result to report error is not watched - but that changing and hence change to error message is almost not a normal scenario
3. file was resolved in a node_modules folder but it appears in node_modules somewhere we would have found before that node_modules lookup - restart tsserver as this seems uncommon scenario,
   Left the tests to fail

Number of watched resolutions went down!! so invalidating time should go down drastically

Info 17690[12:45:13.042] Finishing updateGraphWorker: Project: tsconfig.json projectStateVersion: 1 projectProgramVersion: 0 structureChanged: true structureIsReused:: Not Elapsed: 47915.4494ms
Info 17691[12:45:13.043] ResolutionCache:: {
 "resolutionsWithFailedLookups": 14105,
 "resolutionsWithOnlyAffectingLocations": 4,
 "directoryWatchesOfFailedLookups": 1288,
 "fileWatchesOfAffectingLocations": 3157,
 "resolvedFileToResolution": 11309
}

to

Info 13556[13:26:19.042] Finishing updateGraphWorker: Project: tsconfig.json projectStateVersion: 1 projectProgramVersion: 0 structureChanged: true structureIsReused:: Not Elapsed: 42156.215200000006ms
Info 13557[13:26:19.042] ResolutionCache:: {
 "resolutionsWithFailedLookups": 151,
 "resolutionsWithOnlyAffectingLocations": 0,
 "directoryWatchesOfFailedLookups": 20,
 "fileWatchesOfAffectingLocations": 2796,
 "resolvedFileToResolution": 11309
}

[sheetalkamat]

@typescript-bot pack this

[typescript-bot]

Starting jobs; this comment will be updated as builds start and complete.

Command	Status	Results
pack this	✅ Started	✅ Results

[typescript-bot]

Hey @sheetalkamat, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/165350/artifacts?artifactName=tgz&fileId=2771ED305D29E25E36FCABC5F9002D96578FDF58FFA22A77769BA30DF2B9868C02&fileName=/typescript-5.9.0-insiders.20250613.tgz"
    }
}

and then running npm install.

---

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/[email protected]".;

[sheetalkamat]

@typescript-bot cherry-pick this to release-5.8

[typescript-bot]

Starting jobs; this comment will be updated as builds start and complete.

Command	Status	Results
cherry-pick this to release-5.8	✅ Started	✅ Results

[typescript-bot]

Hey, @sheetalkamat! I've created #61864 for you. This involved updating baselines; please check the diff.

[DanielRosenwasser]

So, for anyone reading this, and my own understanding - the problem is that typically if you do an import of foo, we have to run through many different possible locations to resolve a file. However, even if we find the module, we will still have to install file watchers for all of the locations we looked at before successfully resolving. This is to accurately capture some new file coming into existence and taking precedence. That might be an npm install on an inner directory, or a file with a "higher priority" extension, or something else entirely.

But that is generally uncommon if we've actually resolved a module. And so it sounds like the idea here is that if a module was actually resolved and found, we won't add watchers for any place we would have looked. If you do find yourself in an uncommon situation, you'll need to restart tsserver.

[DanielRosenwasser]

edits to package.json are ignored - most scenarios these edits will be watched for files's mode

Why does this happen anyway? Shouldn't this trigger a re-resolve?

alternate js result to report error is not watched - but that changing and hence change to error message is almost not a normal scenario

This one I'm not clear on - can you elaborate?

[sheetalkamat]

Package.json was watched in two scenarios before this change -

1. if package json was used to determine file's metadata - in node16 etc
2. if this affected already resolved module resolution

Because we arent doing 2 watch any more and node10 isnt using package.json - this discrepency is shown in the test which uses node10

[sheetalkamat]

This is the error message given if module resolution fails: and then the message changes based of if we can find the resolution using node10 or not. With not watching this location (the resolution was to ".js" file) we wil not change the error based on whether you later install @types which is incorrectly typed

[sheetalkamat]

edits to package.json are ignored - most scenarios these edits will be watched for files's mode

Why does this happen anyway? Shouldn't this trigger a re-resolve?

3eb3e21#r2152786800
This shows example of when it doesnt retrigger re-resolve. I can tweak it to watch it if its node10

alternate js result to report error is not watched - but that changing and hence change to error message is almost not a normal scenario

This one I'm not clear on - can you elaborate?

3eb3e21#r2152817116 This shows example and how this comes into play with what error is displayed