module_resolution=none or =explicit

Discussed in-person with @DanielRosenwasser

In google we have performance issues with tsc and with editor plugins. We have tracked this down to the node moduleResolutionKind looking in many locations on a network-mounted disk.

We don't actually want the node moduleResolution, we only want the baseUrl/paths/rootDirs feature known as "path mapping". Put another way, we explicitly list locations for all inputs, and we never want the compiler to stat a file outside of the explicit input locations.

For tsc, we provide a custom CompilerHost that avoids touching the disk, we implement fileExists and directoryExists purely by consulting our file manifest. However, we can't do this trick for editors, which are becoming increasingly unusable.

As an example, we provide interop with Closure Compiler code that declares goog.module, by naming these goog:some.module. This results in the language services looking for a file like goog:some.module.d.ts all over the network-mounted filesystem, even though a later sourceFile in the program has declare module 'goog:some.module'

cc @vikerman @rkirov

Commencez par le comportement de résolution des modules de tsc et les services de langage utilisés par les plugins de l’éditeur. Examinez comment CompilerHost fileExists et directoryExists sont consultés lors de la recherche de modules, puis définissez ce qu’un mode de résolution des modules explicite ou désactivé doit faire pour baseUrl, paths, rootDirs et les modules déclarés. La tâche est terminée lorsque les recherches évitent les emplacements situés en dehors des entrées explicites sans casser la correspondance des chemins.