Repository: TypeScript
Issue: "paths" option should allow untyped entries
Labels: Suggestion,Awaiting More Feedback

## 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.

```js
// 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.

```js
// 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.

```js
// 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:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).