Add support for URI style import

[Jack-Works]

Search Terms

browser es module import url

Suggestion

Related issues: #28985, #19942

In browser and deno, import from a "package" is different from the node style.

// it's valid in browser but not in TypeScript
import lodash from "https://unpkg.com/lodash-es@4.17.15/lodash.js";

// it's valid in deno but not in TypeScript
import { serve } from "https://deno.land/std@v0.24.0/http/server.ts";

Currently there is no way to let TypeScript automatically map the URI to another place like @types/* or $DENO_DIR/deps/https/deno.land/*

The current path can map a simple pattern of import module specifier to another place, but in the URI style import, a more flexible way to map the URI is required.

Proposal

(maybe add a new moduleResolution: browser)
Add a new uriPaths that allows to map from a RegExp to a local path. It will NOT effect the emitted code. Just a way to find the type definition for those URIs.

I'm willing to implement this feature but I'm not sure if TypeScript will accept this.

Use Cases

For TypeScript to find definition file for imports like https://unpkg.com/lodash

Examples

{
  "compilerOptions": {
    "uriPaths": {
      "https://unpkg.com/(.+?)@.+?/.+": "./node_modules/@types/$1",
      "https://deno.land/(.+?)@v.+?/(.+?)/(.+)": "$DENO_DIR/deps/https/deno.land/$1/$2/$3",
      "std:(.+)": "./node_modules/builtin-module-types/$1"
    }
  }
}

This rule map https://unpkg.com/lodash-es@4.17.15/lodash.js to @types/lodash-es

Map https://deno.land/std@v0.24.0/http/server.ts to $DENO_DIR/deps/https/deno.land/std/http/server.ts.

$DENO_DIR is an environment variable.
By default, on Windows, it's ~\AppData\Local\deno\deps\https\deno.land\std\http\server.ts.
By default on Linux, it is ~/.deno/deps/https/deno.land/std/http/server.ts.

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.

[Jack-Works]

Related: #35589

If you find yourself trying to write a valid runtime path, and can't get TypeScript to understand how to resolve that path to the target module, tell us about it.
-- From @RyanCavanaugh

---

Hi @xlaywan, @fatcerberus, @MicahZoltu, @andrewbranch
Please move from #35163 to here!

---

Hi @vladima you implemented the current compilerOptions.paths feature in the TypeScript, how do you think about this issue?

[NemoStein]

Please, don't let this issue die.

VSCode depends on TS to resolve JS modules definitions.
The ability to import a package from a remote server and still have access to intellisense is essential to modern day web development.

[jkrems]

This issue seems to focus on loading / using HTTP URLs. I created a more targeted issue to just support import by URL in general, without supporting module locations beyond what TS already supports today (#41730).

[ExE-Boss]

Also, Node v14.13.1+ supports the node: prefix for importing built‑in modules.

[newtack]

This is also needed for Deno. Typescript mission is a superset of JavaScript and JavaScript does support loading from url/fully qualified file name (including .ts extension).

Can you please add this?

[MMK21Hub]

This also applies to importing from https://cdn.skypack.dev using Snowpack. At the moment, I have to add @ts-ignore whenever I want to use a package. Hopefully, 'Next Meeting' is soon.

[Jack-Works]

And another thing to mention, webpack 5 (or rollup?) supports the mix usage of Node style import and URI style import. They can bundle the Node style import and leave the URI import to the runtime so we must not split Node&URI style into two conflict parts.