-
Notifications
You must be signed in to change notification settings - Fork 12.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Computed import types #44636
Comments
This is a pretty heavy lift from the architecture side since, during the typechecking phase, we generally don't go do new expensive I/O. We could potentially allow it for modules that are already in scope (probably pretty common) but if you already know the completely list of modules you might want to look up this way, it's pretty straightforward to write a helper type somewhere with that list instead of using |
@RyanCavanaugh Doesn't The criteria "module has to be in scope" doesn't apply to If you let me add my subjective 2 cents, this feature is required to correctly type check at least 5 core frontend libraries, so it seems this is quite an important heavy lift to do. |
My use case is that my library has support for mocking dynamic imports. Essentially the api looks like this: const {mockedImport} = await importer.import("path/to/import.js"); The api closely mimics dynamic async importWrapper<T extends string>(url: T) : Promise<typeof import(T)> Right now I'm resorting to using the module itself as a generic parameter. But using it like this is kind of ugly: const {mockedImport} = await importer.import<typeof import("path/to/import.js")>("path/to/import.js") |
Having the same issue with
|
@RyanCavanaugh would it help if there was a new It seems like something like this might be necessary if module expressions land. I imagine module expressions would be type Usage could look like this: function lazyImport <M extends module>(pathOrModule: M): () => typeof import(M) {
return () => import(pathOrModule);
} |
To add one more use case, we use jest in out React application. And jest have ability to mock modules. To keep it typesafe we use the following pattern: jest.mock(
'path/to/module',
(): typeof import('path/to/module') => ({ }),
); If we could use generic import types it would make it less verbose and would remove duplication of path. |
same issue with jest and mocked functions. if you go the road and import the globals (instead of using ambient types),
you can imagine this getting a bit verbose if you need a lot of spies in a test |
When can we expect this to land? |
What's the current status of this feature? Is there an expected support time? |
Suggestion
π Search Terms
β Viability Checklist
My suggestion meets these guidelines:
β Suggestion
Add ability to
typeof import()
a string literal typeπ Motivating Example
π» Use Cases
babel
,eslint
andwebpack
use package names in their API, dynamicallyrequire
them and proxy data into their interface. Generally, API that looks likecould greatly improve on typing with this.
Also it's often the case with dynamic imports that resulting
Promise
gets passed through several other methods (likeReact.lazy
orloadable
from@loadable/component
). Currently the only way to get good types there is to have these duplicated at everyimport()
site. It would be possible to assign some types to wrapper function in this case too.The text was updated successfully, but these errors were encountered: