Import type over generic argument

stephenfhunt commented 5 years ago

Search Terms

import type, generic, module string type

Suggestion

To allow for giving a generic argument as an import() type's argument, something like function <Mod extends string>(obj: unknown, modPath: Mod): obj is import(Mod);

Use Cases

Would allow generic functions that type inference from any module path string literal to the type exported by that module. This is helpful for encapsulating good module loading practices. For instance, in a large AMD application I work on, we need to manage the application footprint by not loading modules that aren't needed for the current execution path. There are a number of utility functions we could write around handling modules to support good behavior on this front.

Examples

One of the signatures of AMD's require() could be typed as: function require<Mod extends string>(path: Mod): import(Mod); This actually does work today if that declaration is put in a .d.ts file and skipLibCheck is set to true. If a string literal is passed, the return type is inferred from the path; if non-literal, the return type is any. In fact, if this worked but disallowed anything other than a module path, it would be super handy for typo avoidance. I'm pretty sure what's happening now is accidental, though, since any more complex use yields a "string literal expected" error on the import type.

Likewise, I'm pretty sure a really useful signature for define() could be done with a mapped type and tuple typed-rest params, something like:

type ImportsOf<Paths extends string[]> = { P in keyof Paths: import(Paths[P]) };
function define<Paths extends string[]>(paths: Paths, callback: (...args: ImportsOf<Paths>)=>void);

Specifically, the function I wanted to write with this was a type-narrowing instanceof check over a module path. Given a module that exports a constructor:

function isModuleInstance<Mod extends string>(obj: unknown, path: Mod): obj is InstanceType<import(Mod)> {
    const modValue = require(path);
    return modValue && obj instanceof modValue
}

If the module for a constructor hasn't been loaded, we can assume no object has been constructed by it, so this technique is very handy for keeping down the module load footprint in applications with lots of modules.

A question for discussion would be the value of an import-type on a non-literal argument, or a non-module argument for that matter. My initial impression is if the import() type can't be resolved, it should evaluate to never and produce an error just like import('some_garbage_string_i_made_up')". That might require the type checker to be given a stricter bound than "extends string", though. If necessary, a user-visible built-in type that means "a string representing a known module" seems like it might be useful in lots of contexts.

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.)
[Seems like it to me] This feature would agree with the rest of TypeScript's Design Goals.

Raynos commented 5 years ago

:+1: this feature would also allow const foo = require('foo') to work similary to import foo = require('foo') because we can use this feature to define the type of require

njakob commented 4 years ago

Maybe supporting readonly for string constraints would help?

Consider the following example in order to type require:

declare function require<T extends const string>(path: T): import(T);

Since import expects a string literal (aka String literal expected.ts (1141)), marking the generic parameter as literal would match this requirement.

ExE-Boss commented 4 years ago

An alternate approach would be to have import(T) resolve to unknown when T is string,

thetutlage commented 4 years ago

This will also help a lot with lazy loading. For example: Currently we define data model factories in a single file and that file is full of Model imports

import User extends './app/Models/User'
Factory.define(User, () => {})

We have around 50 models and this file has 50 imports. Yes, I agree, that are alternatives like

Split factories into multiple files
Use factory functions to enable lazy imports.

But if this feature is considered by the Typescript team, then it will be the 3rd (and probably the best) alternative for us

JanVoracek commented 3 years ago

Mocking (e.g. using Jest) could also benefit from this.

namespace jest {
    function mock<M extends string>(moduleName: M, factory?: () => Partial<typeof import(M)>, options?: MockOptions): typeof jest;
}

jest.mock('./some-module', () => ({ someTypoInName: jest.fn() }));
//                                  ^--- 'someTypoInName'  does not exist in type ...

avidcoder123 commented 3 years ago

This would be valuable for intellisense relating to different modules

Peeja commented 3 years ago

Combined with template literal types, this would also allow (eg.) ESLint to offer a config type which accounts for the config options for each available plugin.

kommander commented 2 years ago

Any news on this? 👀

pi0 commented 3 weeks ago

This feature could also be useful for jiti to allow typing jiti.import(id).

microsoft / TypeScript