Feature Request: `import defer`

[robpalme]

Feature Request: TC39 Stage 3 import defer

Proposal repo: https://github.com/tc39/proposal-defer-import-eval

The new import defer syntax is at Stage 3 in the TC39 process and implementations are starting to move forward in browsers and tools.

This enables new optimizations in code splitting builds that avoid unnecessary code execution.

Example:

import defer * as mod from './mod.js';

export function lazyModUser () {
  mod.foo();
}

where mod is a "Deferred Module" flavor of Module Namespace, whose accessors (including e.g. reading keys) cause evaluation to run.

Desired support

At a minimum the syntax should be tolerated. Ideally this should be a fully compliant downlevel as that will benefit users the most. That requires function-wrapping the modules that will be lazily evaluated, i.e. they cannot be inlined (scope-hoisted).

References

• import defer proposal is Stage 3
• Babel shipped support - only works with CommonJS output
• webpack merged experimental support with some caveats
• TypeScript 5.9 Beta shipped support - syntax passthrough, no downleveling
• Rollup issue
• Rolldown issue
• RsPack issue
• Deno issue

[evanw]

I can add support for this syntax in the next release. And also for the source syntax that seems to be intended to go with this feature. Source phase imports actually seem to have more traction than deferred imports as implementation has started in Chrome.

This enables new optimizations in code splitting builds that avoid unnecessary code execution.

It looks like the specification might require the usage of Proxy objects to implement correctly as a bundler? That's unfortunate, as it seems like that would be a non-obvious and potentially significant performance deoptimization for code using this feature. Hopefully I'm misunderstanding something and this isn't actually the case.

I guess if the compiler is fancy it could only create the proxy object if the module namespace exotic object ever escapes (i.e. is used for something other than a direct property access), and insert an inline initialization function call otherwise. That would limit the blast radius of the performance impact. Still it seems strange that a performance-oriented feature would have such a big performance foot-gun.

[robpalme]

Thank you for implementing syntax support. That is appreciated.

Necessity of Proxy

You are correct that non-native implementations need to use Proxy in the general case, and that can be skipped with escape analysis. Both tool-based implementations that exist today (Babel, webpack) implement this optimisation. Meaning they only generate a Proxy if the namespace is leaked. Here are demos of that in Babel and webpack.

Personally I think this is a good trade-off because the common-case in user code is to use module namespaces for trivial dereferencing of properties, rather than exporting the deferred namespace or passing the namespace around as a parameter. There's also the potential for helpful lint rules to accompany import defer to further guide user behaviour towards high performance usage. For example, an obvious misuse is unconditional top-level usage of a deferred import, i.e. eager use of a lazy thing. We have some experience of such linting in the Bloomberg implementation that we have been using for the last two years.

Cost of Proxy

It's absolutely true that ES2015 Proxy is one of the most heavyweight JS language features and it had a massive polyfill to accompany it that impacted bundle sizes and runtime performance. Happily native implementations have been widely available for roughly a decade now. The native implementations remain somewhat costly for fundamental reasons, but over that decade they have been subject to directed efforts. So I think Proxies don't need to be feared as much as they were in the past.