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?

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.

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.

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

(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.