Better reuse of package.json cache, module resolution cache, and package.json auto import filter

[andrewbranch]

I made a test project that contained a lot of dependencies with export maps to ensure the new code paths were being hit. The slowdown from main to #47092 can largely be explained by the fact that we’re finding more things to auto-import, as the baseline case completely ignored those export maps. The cache reuse pays off in collectAutoImports, where previously we had to read package.jsons that have already been read and cached. Note that getExportInfoMap and collectAutoImports are components of completionInfo, which is the “bottom line” perf number for the server-side work of getting completions.

	dev.20220109	#47092	This PR
createAutoImportProviderProgram	354 ms	395 ms	408 ms
AutoImportProvider files	6	30	30
getExportInfoMap	34 ms	48 ms	44 ms
collectAutoImports	89 ms	98 ms	76 ms
completionInfo	246 ms	245 ms	230 ms
completion entries	3075	3149	3149

[amcasey]

Some very basic questions, since this isn't really my area:

1. The cache is from package.json path to package.json contents (as a string?)?
2. What's the cache used for now? Are we using it outside its former lifetime?
3. When is the cache updated?
4. Does the new code only read from the cache or can it update it as well?
5. How do we guard against the cache getting too big?

[andrewbranch]

1. package.json path to contents (as an object, but I think only with resolution-relevant keys)
2. The new usage is simply reading package.json contents for module specifier generation rather than reading the file from disk. The lifecycle is unchanged.
3. As part of module resolution generally; this is a question for @weswigham
4. Read only
5. Also a question for @weswigham, but I’m pretty sure the answer is “we don’t” and also, assuming that on average, a dependency contains more TypeScript code than resolution-relevant package.json fields, we will run out of memory on the former long before the latter can begin to be problematic.

[weswigham]

Yeah I don't think the cached json is going to be a problem before the code itself is a problem given normal ratios of the two.

[amcasey]

4. Not updating the cache is to keep this change safe and conservative?

[amcasey]

Seems reasonable.

[andrewbranch]

(4) is because there’s simply no new information to write back to the cache. In order to have files available for auto-import in the first place, module resolution already had to find them and read their package.jsons. Theoretically we shouldn’t hit one we haven’t already seen. Updating a cache that belongs to module resolution outside of module resolution does feel sketchy, and I would probably avoid it. But in this case there’s nothing to update.