Feature Request: dynamic import with type parameter

[shigma]

Suggestion

🔍 Search Terms

dynamic import

✅ Viability 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, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Support dynamic import() with type parameter.

📃 Motivating Example

Assuming we are developing a framework which implements a CLI that accept such config file:

// xxx.config.ts
import { AppConfig } from 'libxxx'

export default {
  plugins: {
    'foo-plugin': { bar: 'baz' },
  },
} as AppConfig

will be equal to

import { App } from 'libxxx'
const app = new App()

// apply plugin with options
app.plugin(require('foo-plugin'), { bar: 'baz' })

The foo-plugin package can be like this:

import { App } from 'libxxx'

interface Config {
  bar: string
}

export function install(app: App, options: Config) {
  // implementation
}

But we can't get code hints from plugins, because we do not have typings support for dynamic imports.

💻 Use Cases

// libxxx.d.ts
export interface AppConfig {
  plugins: {
    [K in string]: import(K) extends (app: App, options: infer T) => any ? T : never
  },
}

[NWYLZW]

++

[andrewbranch]

Interesting idea, but there’s already an easier way to do this. Each plugin package can augment an interface from the main lib:

// foo-plugin:
import { App } from 'libxxx';

// Add 'foo-plugin' member to `PluginConfig` already declared in 'libxxx'
declare module 'libxxx' {
  interface PluginConfig {
    'foo-plugin': Config;
  }
}

interface Config {
  bar: string;
}

// ...

You can find lots of examples of this on DefinitelyTyped, e.g. for Express middleware packages. See how express-boom patches a property onto express’s Response interface.

[shigma]

@andrewbranch I know, but in your case, it seems that we have to import all the 'foo-plugin's into our config file, which is quite annoying......

// xxx.config.ts
import { AppConfig } from 'libxxx'

// if we didn't do this, ide would not show proper code hints
import {} from 'foo-plugin'
import {} from 'bar-plugin'
import {} from 'baz-plugin'

export default {
  plugins: {
    'foo-plugin': { bar: 'baz' },
  },
} as AppConfig

[andrewbranch]

That’s a good point. I would suggest putting them in the types field of your tsconfig.json instead (I’m pro-manual-management of types), but, it’s the same amount of manual work.

[DanielRosenwasser]

Seems like a duplicate of #26139 (and #42482) right?

[andrewbranch]

I think you might have mistyped the number on the second one? But yeah, duplicate of #26139 at least in terms of the answer.

[DanielRosenwasser]

Fixed to #42482.

[shigma]

Oh I see. It there possibility to introduce this feature in the future, or as is said in #26139 it was hard to fix?

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.