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

[FredKSchott]

Bump again: @RyanCavanaugh I know the team has said no to getting involved with import resolution (re: #16577) but I just wanted to make sure that this different use-case/ask didn’t get wrapped into that decision incorrectly.

The idea that import "./App.ts" is invalid assumes a Node.js or browser environment. But different environments like Snowpack and Deno support importing TS files. In Snowpack’s case, it’s part of a larger handling of importing source files by source name, so that something like import "./App.svelte" is valid. Because Snowpack handles your build, we are able to resolve the import correctly at build time. But for TS, this behavior is broken.

It would be really useful if this warning could suppressed via an opt-in compiler option, for environments like Deno and Snowpack where importing the TS file by path is actually the correct user behavior.

This request is aligned with the decision in #16577 imo, because we are specifically not asking for any sort of resolution/rewriting of imports.

/cc @kitsonk

[FredKSchott]

Wanted to bump this thread since Snowpack TS users are also running into problems with TypeScript’s reliance on Node.js module resolution logic. More info: https://github.com/microsoft/TypeScript/issues/27481

TypeScript users on Snowpack are also running into this issue. ESM imports in Snowpack are based on the source filename, so import './file.ts' and import Counter from './counter.tsx' are both expected to work. We ask TS users to use the “.js” file extension as a workaround, but we’re looking to add new features that might break this for them entirely.

It feels odd that TypeScript wants to both stay out of import resolution (the right call, imo) but also put arbitrary limits in place. I’m +1 this warning as a default to protect new users from footguns in most projects, but projects like Deno and Snowpack should be able to suppress this.