Shouldn't TypeScript be able to polyfill `import defer` with `Proxy` to work with `"module": "commonjs"`?

[KSXGitHub]

🔍 Search Terms

import defer commonjs
import defer require

✅ Viability Checklist

• 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Since the TypeScript beta announcement, I tried it in the playground. But setting "module" to "commonjs" sadly revealed that import defer only work with "module": "esnext" or "module": "preserve".

But Proxy can polyfill this exact behavior.

📃 Motivating Example

This code:

import defer * as MyModule from 'my-module'

should output something like this:

let _module
const MyModule = new Proxy({}, {
  get(_target, prop) {
    if (!_module) {
      _module = require('my-module') // the real code would obviously more complicated as it needs to force `_module` to be an object
    }
    return _module[prop]
  }
})

💻 Use Cases

1. What do you want to use this for? Using import defer for legacy targets
2. What shortcomings exist with current approaches? await import forces Promise
3. What workarounds are you using in the meantime? await import

[snarbles2]

Worth pointing out that import defer pre-fetches the module and defers evaluation, whereas the proposed implementation also defers fetching the module.

The import defer proposal offers this remark regarding this sort of lazy-loading workaround.

It doesn't actually solve the deferral of execution problem, since sending a network request in such a scenario would usually be a performance regression and not an improvement. A separate network preloading step would therefore still be desirable to achieve efficient deferred execution while avoiding triggering a waterfall of requests.

That's with respect to a workaround involving await import. Using require has additional performance implications because it is blocking.