Do you have a specific use-case in mind? Contextualizing what you're running into and why current workflows aren't sufficient would be helpful.

This would be useful when using remote modules via unpkg without npm installation.

Do you have a specific use-case in mind? Contextualizing what you're running into and why current workflows aren't sufficient would be helpful.

I'm developing a client-side library right now and its components are file seperated with es2015 modules.
So i want to be able to import remote modules.

import { Slider } from "http://www.mycompany.com/UIKit/"

And this actually works for me but i can't actively using it since there is a red line under every import and basically its type is any so no reason to use typescript with it. I'm currently switching to babel with @babel/typescript preset so i can edit my code in compile time but i want typescript features in my vscode. I want my project to be free of node_modules folder except compiler as much as possible. I hope this clarifies my use-case.

gotcha; in the meantime you could possibly use path mapping, but I understand why this is less-than-desirable.

Importing remote modules is where the js community is headed. This is a thing in https://deno.land/ and now browsers are natively supporting this via <script type="module">. I would love to see seamless typescript tooling in these scenarios.

I'm new to this repo so i don't really know release cycle. What kinda life cycle these issues have or when we can prototype it ?

Is there going to be anything further on this issue? As @bradenhs says, deno is a thing and there is actually an issue open (denoland/deno#1432) for supporting something like this. One suggestion I had was very similar to the one proposed here, which is something like:

/// @ts-defs https://example.com/definitions/mod.d.ts
import "https://example.com/modules/mod.js"

For deno, the suggestion is now // @deno-defs to prevent using the @ts- space, but if it was natively supported, it would be very useful.

I made a solution for it:

1. Install the types file: yarn add -D @types/Component1
2. At the project folder, create a declaration file modules.d.ts with content:

module 'http://example.com/Component1' {
  import content = require('Component1');

  export = content
}

3. enjoy

import everything from 'http://example.com/Component1'

We have to have a local declaration for supporting intelligence

I have a use case for it. In minimal environments you do not want to use npm or lots of files. Assume you want to edit a single JavaScript file (a script doing calls to an API) with Visual Studio Code. If you can reference remote declaration files (e.g. public git repository with the type declaration of that API) you will benefit from better tool support by only adding a comment on top of that file.

I am currently using the new import maps feature in Google Chrome. This allows me to use the following:

import { h, render, Component } from 'preact';
import Router from 'preact-router';

My import map:

<script type="importmap">
      {
        "imports": {
          "preact": "https://unpkg.com/preact@10.0.5/dist/preact.module.js?module",
          "preact-router": "https://unpkg.com/preact-router@3.1.0/dist/preact-router.es.js"
        }
      }
</script>

I only need the node_modules folder for the declaration files to make VS Code happy. I wish there was a way to fetch the declaration files from some url. Maybe adding it to the tsconfig like so?:

"paths": {
      "preact-router": [
        "https://unpkg.com/preact-router@3.1.0/index.d.ts"
      ]
}

This is just an idea but I could get rid of the node_modules folder entirely this way. To ensure compatibility with other browsers that don't support the import maps yet I could easily have a script that replaces imports with the url found in the import map.

I was thinking about creating an extension for VS Code that would fetch the declaration files on the fly but adding a remote path to some config (tsconfig?) sounds even better.

Module Federation could be a great scenario?

I, too, am using import maps (through the SystemJS polyfill) and would love a feature like this. When a library is updated, it gets updated in the import-map and is never yarn/npm installed to node_modules, so it seems like a remote URL would be the best solution for that setup.

A couple of questions, however -

• how often would TS check for remote .d.ts file updates?
• can the dev force a recheck?
• would maybe some checksum hash (in the file itself? as part of the file name?) be helpful in letting TS know that it either doesn't need to download/write the .d.ts file again or that it needs to?

(this is with the assumption that TS downloads a copy of the .d.ts file as a local cache - but maybe TS doesn't need to do that?)