Re emit: I’m in favor of what you have now, not changing what the user wrote in the directive.

As-is, thisalways emits the appropriateresolution-mode in the directive, weather it was originally explicitly written or not.

Oh, I misunderstood. Hm, I’ll have to think about that. I think it complicates the library code problem more. If you happen to compile your library in nodenext but resolution would work for consumers under commonjs, it would be a shame to have errors on those references just for including superfluous syntax.

I think on principle I lean toward leaving code the user wrote as-is unless there’s a good reason it needs to be changed.

I now omit theresolution-mode override if it's unneeded in the resulting file, so they're notusually present. While preserving the input formatting where possible sounds nice, to do so needs context about where the original comment came from preserved (so we know when we have to change that formatting), which, since it's derived from a comment, is not the case right now (unlike nodes, which retain pointers back to their original source,FileReferences contain no such data and get copied around willy-nilly - we happily pull type references from random other files in your build!). It's probably doable, but'd complicateFileReferences a bit, since they'd need to somehow inherit their original file's applied resolution mode.

I've mentioned it in some linked issues, but the cache changes in this PR also happen to fix some language service issues to do with format detection caching, and as such this now includes a test to that effect. ♥

In theresolutionCache, themode wasn't consistently handed in by all callers before, which wasn't obvious prior to this PR because triple-slash references intentionally didn't pass a mode.

Specifically, it wasn't being propagatedhere.