Open stephenfhunt opened 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
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.
An alternate approach would be to have import(T)
resolve to unknown
when T
is string
,
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
But if this feature is considered by the Typescript team, then it will be the 3rd (and probably the best) alternative for us
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 ...
This would be valuable for intellisense relating to different modules
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.
Any news on this? 👀
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:
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:
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: