ES6 modules not found when loaded over network

[hindsholm]

Issue Type: Bug

ES6 modules can be loaded over HTTP(S) like this:

import { LitElement, html } from 'https://dev.jspm.io/lit-element@2.0.1/lit-element.js';

This works fine in any modern browser since it is standard ES6 and I find it very convenient for small projects because it allows you to completely avoid the complexity involved with npm and packagers.

However, VS Code complains with a red underline and the mouseover error message:

Cannot find module 'https://dev.jspm.io/lit-element@2.0.1/lit-element.js'. ts(2307)

It would be great if VS Code did not complain about this (since it is possible to find the module) and even better of course, if the module could be resolved correctly like locally-loaded modules.

VS Code version: Code 1.31.0 (7c66f58312b48ed8ca4e387ebd9ffe9605332caa, 2019-02-06T08:51:24.856Z)
OS version: Linux x64 4.20.6-arch1-1-ARCH

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz (4 x 3084)
GPU Status	2d_canvas: enabled checker_imaging: disabled_off flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software rasterization: disabled_software surface_synchronization: enabled_on video_decode: unavailable_off webgl: enabled webgl2: enabled
Load (avg)	1, 1, 1
Memory (System)	11.60GB (0.27GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions (20)

Extension	Author (truncated)	Version
swagger-viewer	Arj	2.2.0
rest-client	hum	0.21.1
plantuml	jeb	2.10.3
Kotlin	mat	1.7.0
rainbow-csv	mec	1.0.0
python	ms-	2019.1.0
openhab	ope	0.4.1
vscode-template-literal-editor	pli	0.9.0
java	red	0.38.0
vscode-xml	red	0.3.0
LiveServer	rit	5.4.0
es6-string-html	Tob	1.8.6
vscodeintellicode	Vis	1.1.3
vscode-apielements	vnc	0.6.7
vscode-java-debug	vsc	0.16.0
vscode-java-dependency	vsc	0.3.0
vscode-java-pack	vsc	0.5.0
vscode-java-test	vsc	0.14.0
vscode-maven	vsc	0.14.2
vscode-wakatime	Wak	1.2.5

(1 theme extensions excluded)

[RyanCavanaugh]

Not pulling arbitrary http endpoints is intentional. You can declare the module using its URL:

// .d.ts file
declare module "https://dev.jspm.io/lit-element@2.0.1/lit-element.js" {
    export const LitElement: any, html: any;
}

// Elsewhere
import { LitElement, html } from 'https://dev.jspm.io/lit-element@2.0.1/lit-element.js';

[hindsholm]

Thx for the tip about declaring a module by its URL. It helps, but in order for it to be really useful, you typically have to add quite a bit more type information than any, e.g.

declare module "https://dev.jspm.io/lit-element@2.0.1/lit-element.js" {
    export declare class LitElement extends HTMLElement {
        requestUpdate(name?: PropertyKey, oldValue?: unknown): Promise<unkown>;
        ...
    }
    export const html: any;
    ...
}

I still think it would be great if there was an option to turn on pulling http endpoints just like the ES2015 runtime system in a browser does, since it would make the kind of development/prototyping that I described above much easier and even more productive.

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[jhpratt]

@RyanCavanaugh Is there a way to pull in the type definitions while simultaneously relying on a network import? I'm trying to do the exact same thing as @​hindsholm. There's no reason to pull in all the code when it can be served via CDN.

Edit: Found this. Unfortunately, for libraries like lit-element, this means you still have to have the entire library locally, as a @types package isn't published (types are included).

[cdata]

Something that I would like to call out is that the package in question is authored in TypeScript and publishes its type declarations alongside the other build output. Why should we re-declare all of those types?

I also arrived at the solution of loading from a CDN after reading the following advice given in a separate thread:

Our general take on this is that you should write the import path that works at runtime, and set your TS flags to satisfy the compiler's module resolution step, rather than writing the import that works out-of-the-box for TS and then trying to have some other step "fix" the paths to what works at runtime.
We have about a billion flags that affect module resolutions already (baseUrl, path mapping, rootDir, outDir, etc). Trying to rewrite import paths "correctly" under all these schemes would be an endless nightmare.

Excerpt taken from this older thread.

To lay out the scope of my problem:

• Say I'm trying to write some TypeScript that will be transformed to JavaScript and run in a browser
• My code depends on some external modules that are available from npm or unpkg.com
• Browsers support full-URL, cross-domain module specifiers at runtime
• tsc supports Node.js-style resolution, but cannot re-write Node.js module specifiers in the output
• Also, tsc won't recognize modules that are imported from a CDN

So my options to write TypeScript and deploy to the browser are:

• Import everything by relative paths in my module and ...
  • ...make sure none of my transitive dependencies depend on Node.js-style module resolution or
  • ...transform Node.js-style name specifiers in my source tree ahead of time
    • Note: unpkg.com does this for us with the ?module query param
• Use a bundler or similar transform to fix module specifiers in the compiled output
  • ...and what happens to my source maps in this case?

It seems like something important is missing here.

[cdata]

(the missing thing may be Import Maps, but those don't technically exist yet)