Feature: Is ‘import()’ for dynamic module loading really the best name?!?

Do you want to request a feature or report a bug?
Feature request.

What is the current behavior?
Dynamic module loading is using ‘import()’. Alternatives are ‘require.ensure()’ (non-portable) and ‘System.import()’ (deprecated). See https://webpack.js.org/guides/code-splitting-import/ for more details.

If the current behavior is a bug, please provide the steps to reproduce.
The problem of using ‘import()’ is that ‘import’ is a KEYWORD in the TypeScript compiler. Hence TypeScript will not compile ‘import()’. In no configuration. And even not if you compile JS with the TypeScript compiler.

What is the expected behavior?
You probably should not use an already used keyword for dynamic module loading. ‘System.import()’ was ways better in this respect.

If this is a feature request, what is motivation or use case for changing the behavior?
Could you rename ‘import()’? Or at least provide an alias for it?

Author: Fantashit

1 thought on “Feature: Is ‘import()’ for dynamic module loading really the best name?!?

  1. Yes, it’s a problem with TypeScript. For now, your best approach is to use System.import, which you can easily find/replace with plain import once TypeScript gets support for it; they work exactly the same way, only the latter is an official TC39 thing.

    interface System {
      import<T> (request: string): Promise<T>
    }
    declare var System: System
    
    import * as fooNs from 'foo'
    const foo = System.import<typeof fooNs>('foo')
    // The `typeof fooNs` thing is a hack to get the Promise to be correctly typed,
    // which leads to:
    foo.then(foo => {
      // foo has correct typechecking, autocomplete support, cross-references, etc
    })
    // because you only referred to fooNs as a type,
    // TypeScript will delete the import..from before webpack sees it

Comments are closed.