Import Interfaces and/or definitions from URL's pointing to Servers (Not local to machine)

Search Terms

• import url
• import web address
• import from server

Suggestion

Hello, My thought process behind this is allowing strictly typed API's to be served for developers to have an easier time developing/consuming API's.

What I am suggesting probably has implications reaching far past my goal such as importing modules or variables or other things over the web which would impact runtime or require downloading resources at compilation time, I do not wish to dive that deep as my purpose is strictly for typing of objects and possibly typescript definition files that are only used during development, I will let any possible discussion delve further into those other topics.

API's are often served at endpoints such as https://www.foo.com/_api/bar; and when we developers want to consume these API's using typescript we have two options, Declare our response object as any, or write an interface that maps what we need from the API so that intellisense can recommend GetNumberOfLegs from our imported object Animal.dog.Get...

Would it be possible to allow the Typescript compiler to evaluate a url like this one (Gist URL Below) during the development/linting phase and utilize the type at that endpoint? This could be done in my case for typing objects that appear in multiple projects by hosting files like this at a publicly available endpoint, or also allow API endpoints to provide an interface that our typescript compilers could read and utilize during development. If used for definition files, then the package manger install of a separate package for third party definitions of a library would also be rendered not needed.

I imagine we would have an import statement at the top of our file that instead of pointing to a local path, would simply point to a web address.
import myObjectInterface from 'https://www.foo.com/_api/v1.3/interfaces/bar';

Non Raw Gist Url:
https://gist.github.com/Metroidaron/48b6bb2ea0cb7b8b2d0e81f82a62ffb6

Use Cases

I want to use this to centralize my own object types that are relevant across multiple projects by creating public interfaces that all my work projects can point to, the current pitfalls of the current system are that to accomplish synchronization across projects and consistency, I would need to either create and install an NPM Package (or some other package manager), use Git SubModules to maintain separate git repositories inside project repositories, or simply copy/paste files.

This would also allow for API's to provide interfaces to the developer, this would increase development speed because there would not be a need to translate an API into an interface for use in a project while maintaining full and accurate strict typing. If an API is strictly typed behind the scenes, I think it would likely be fairly strait forward for the generation of these files to be automated.

Examples

Example 1

import iBasicSampleObject from 'https://gist.githubusercontent.com/Metroidaron/48b6bb2ea0cb7b8b2d0e81f82a62ffb6/raw/1479fc1271eddd1dfef12ccd9da028f546899fe1/BasicSampleObject.ts';
import iEasierToReadExample from 'https://www.foo.com/_api/v1.3/interfaces/bar';

fetch('https://www.foo.com/_api/v1.3/bar', {}).then( httpResponse => {
  httpResponse.json().then( (bar : iEaserToReadExample) => {
    // Bar is now strictly typed based on what the API defines Bar's Type should be. 
    bar.getFunctionOne();
  });
});

Example 2

import iRemoteUserObject from 'https://www.CompanyWebsite.com/DevelopersStuff/iUserObject.ts';

const UserObject : iRemoteUserObject = {
  name : 'Metroidaron',
  ageBracket : 'old'
}

/**
 * UserObject is strictly typed from an external source
 * and can be imported into my companies external website, employee portal, desktop App, Mobile app, and more.
 */
UserObject.ageNumber

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.

Start by reviewing the TypeScript compiler's handling of import statements and module resolution, focusing on how a remote URL could be evaluated during development without changing emitted JavaScript. Compare the proposal's remote interface and definition-file examples, then define how fetching, caching, failures, and completion would be handled before implementation.