Support string types in dynamic import types.

[everett1992]

Search Terms

dynamic import type

Suggestion

I'd like to define a function that wraps a dynamic require or import. Specifically, I'm writing a library that uses node's worker_thread and I want to support 'dependency injection' via dynamic import. You can't pass class instances or functions across execution contexts.

import { isMainThread, Worker, workerData } from 'worker_threads';

export type LoggerImportPath = ???;

export default function lib(logger: LoggerImportPath): Worker {
  return new Worker(__filename, { workerData: { logger });
}

if (!isMainThread) {
  const module: { default: Logger } = await import(workerData.logger);
}

// no type error, ./path/to/logger exports a Logger.
lib(`${__filename}/path/to/logger');

// this should be a type error: import('not-a-module') is not assignable to { default: Logger };
lib('not-a-module');

I don't think you can currently define LoggerImportPath any more precisely than string and import(path: string) returns Promise<any>.

// this returns `{ default: Logger}`
await import('path');

// this returns `any`
const wrapper = path => import(path);
const module: any = await wrapper('path')

Use Cases

I haven't seen this pattern in any other libraries, but I think it's a good way to pass classes or functions across threads or execution contexts. You can't currently limit the kinds of strings that library uses can pass when a module path is expected.

Examples

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.

[fatcerberus]

Regular expression types would probably solve this nicely: #6579

[everett1992]

Regular expression types would probably solve this nicely: #6579

<#6579> I don't want to assert that the string looks like a path, I want to assert that there is a module accessable at the path, and that the imports of the module have a given shape.

…

On Mon, Aug 5, 2019, 8:02 AM Bruce Pascoe ***@***.***> wrote: Regular expression types would probably solve this nicely: #6579 <#6579> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#32705?email_source=notifications&email_token=AAE6WM4CJWKYA7B2NWKEMY3QDA6HLA5CNFSM4IJGG3J2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3SC4MY#issuecomment-518270515>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAE6WM2B5WZ2DRTGBVVEKY3QDA6HLANCNFSM4IJGG3JQ> .

[RyanCavanaugh]

Open to feedback here but we'd have to have some very strong and compelling use cases to investigate further.

The process of constructing a "program" (the set of files under analysis) begins by following static constructs like import * as id from "p" to look for other files to load. Once this file-finding process finishes, the set of files is effectively closed and from there many, many assumptions are made on the basis that no new files will show up later. So this import construct would have to either be restricted to loading modules which are already part of the program (which is kind of weird) or would require an extremely large architectural rejiggering of TS itself.

[everett1992]

I'll assume that dynamic import await import('foo') is included in the static constructs that you mentioned.

I can think of one way to implement this without much rejiggereing.

• Add a typescript syntax import.later(path: string-literal) with the same static constraints as current await import(path: string-literal) (bikeshed the name later :)).
• import.later(path: string-literal) compiles transparently to the string-literal
• import.later(path: string-literal) has the type string & Module<T> where T is the same shape a await import(path) and Module is a marker type.

async function factory(path: string & Module<{default: Logger}>): Logger {
   return import(path).then(module => module.default);
}

factory(import.later('./path-to-module'));

This feels like a hack, so feel free to resolve this issue. IMO this pattern will become prevalent if people start authoring libraries that use web workers or worker threads, but I don't think there's much demand for the feature right now.