Watch mode doesn't correctly invalidate failed subdirectory lookup results

[RyanCavanaugh]

TypeScript Version: 2.8.0-dev.20180318

Search Terms: watch mode subdirectory

Code

You'll need 4 files

// tsconfig.json
// FOR THIS BUG, ORDER MATTERS IN THE FILE ARRAY
{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs"
  },
  "files": [
    "foo/a.ts",
    "foo/bar/b.ts"
  ]
}

// foo/a.ts
import * as q from 'qqq';

// foo/bar/b.ts
import * as q from 'qqq';

// node_modules/qqq/index_.d.ts
export { }

Run tsc -w:

20:37:52 - Starting compilation in watch mode...
foo/a.ts(1,20): error TS2307: Cannot find module 'qqq'.
foo/bar/b.ts(1,20): error TS2307: Cannot find module 'qqq'.
20:37:54 - Compilation complete. Watching for file changes.

Rename index_.d.ts to index.d.ts:

20:38:26 - File change detected. Starting incremental compilation...
foo/bar/b.ts(1,20): error TS2307: Cannot find module 'qqq'.
20:38:26 - Compilation complete. Watching for file changes.

Expected behavior: In the second compilation, b.ts should be able to correctly resolve qqq.

Actual behavior: Failure as shown above. Reversing the order of files in the files array produces the expected behavior.

Playground Link: N/A

Related Issues: None?

[RyanCavanaugh]

The issue here is that when we do the lookup for qqq from foo/, we store the result that a lookup is known to fail. We track the list of failed lookup locations produced from this.

During the lookup of qqq from foo/bar/, we produce a smaller set of failed lookup locations, then go up a folder and see that we've already tried to resolve that module from that location, so we cut the search short. But we don't concatenate the list of failed lookup locations that the earlier search generated.

As a result, when node_modules/qqq/index.d.ts appears, we correctly identify that a.ts needs to have module resolution redone, but b.ts is still only waiting for foo/bar/node_modules/qqq to show up.

When this process happens in the other order, foo/ can't re-use the lookup results from foo/bar/ and the bug does not manifest.

Fix in progress is to store the failed lookup locations in the cache along with the lookup result.