"paths" option should allow untyped entries

Search Terms

paths option untyped declare module

Suggestion

The existing "paths" option allows you to control the types used for bare specifiers in your source code, by mapping them as keys to a list of candidate target specifiers.

// tsconfig.json
{
  "paths": {
    // <bare-specifier>: [ <candidate1>, <candidate2> ]
    "foo": [ "external-foo", "fallback-foo" ]
        // if "external-foo" is not found, "fallback-foo" will be attempted, otherwise error
  }
}

I suggest we allow the final element in the array of candidates to be the empty string "". If hit, it would mean "This module exists but is untyped."

Use Cases

Our build system uses "paths" to implement a searching loader for typed dependencies. We know all the acceptable source specifiers ahead-of-time, and so create one property for each - this ensures precise auto-completions for external dependencies in VS Code. We do not know if the target specifiers will exist on disk or not, e.g. the user may not yet have populated the disk via "npm install".

Strict: Some users want to be strict and see errors if no match was found. This behavior comes for free from "paths" today.

Sloppy: Sometimes users want to be sloppy and have the source specifier be typed as any if no match was found. This behavior is not possible today because there is no way to express "this modules exists but is untyped" in "paths" today.

Workaround

We have not discovered any alternative that allows sloppy behavior to be implemented.

The closest workaround is to write declare module "foo" in an ambient declaration file. However this does not work because it clobbers (takes precedence over) the same entry in "paths". Our desire is for untyped behavior to be the last resort, not the first choice.

Examples

Current behaviour: This works today and is fine for implementing strict behavior.

// tsconfig.json
{
  "paths": {
    "foo": [ "external-foo", "fallback-foo" ]
        // assume "external-foo" and "fallback-foo" do not exist on disk
  }
}

// index.ts
import aDefaultImport, { aNamedImport } from "foo";  // Error(2307): Cannot find module

Proposed behaviour: Here's how we could achieve sloppy behavior.

// tsconfig.json
{
  "paths": {
    "foo": [ "external-foo", "fallback-foo", "" ]
        // assume "external-foo" and "fallback-foo" do not exist on disk
  }
}

// index.ts
import aDefaultImport, { aNamedImport } from "foo";  // no error

The usage of "foo" would result in no compile-time error.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

No files, tests, or entry points are named. Start by locating the compiler's handling of tsconfig.json paths and module resolution, then trace how a final empty candidate could represent an untyped module. Done means the proposed configuration compiles imports without errors when earlier path candidates are absent.