Import Reflection for Stage 2

Currently: Stage 1

​

July 2022 TC39 Meeting

​

Guy Bedford (OpenJS Foundation)

Luca Casonato (Deno)

https://github.com/tc39/proposal-import-reflection

Import reflection

This proposal allows ES modules to import a reified representation of the compiled source of a module when the host provides such a representation:

​

​

​

​

​

Only the above form is supported - named exports and unbound declarations are not supported.

https://github.com/tc39/proposal-import-reflection

Dynamic import

Import reflection in dynamic import is supported through an options bag on the dynamic `import`.

​

​

https://github.com/tc39/proposal-import-reflection

Proposal Scope

Scope has been further narrowed down to the following single scenario:

• Module reflection:�A loaded and compiled but unlinked and unexecuted module object.

​

Asset reference reflection is not in scope for this proposal. We will continue to consider implications for the asset references proposal during the design process though.

https://github.com/tc39/proposal-import-reflection

Keyword instead of arbitrary literal

The reflection attribute is now a keyword, not a literal.

Makes it clear that reflection attributes are not an arbitrary options bag for imports.

Makes it clear what reflection attributes may be used for.

It discourages toolchains from misusing the reflection attribute syntax space for evaluator attributes.

https://github.com/tc39/proposal-import-reflection

WebAssembly Modules

​

The best we have right now:

https://github.com/tc39/proposal-import-reflection

Wasm Instantiation Today

​

• Even with the WebAssembly ESM integration, there will always be a need to load a direct WebAssembly.Module.
• The syntax today is very complex and easy to get wrong:
• Forget the new URL(‘./app.wasm’, import.meta.url) pattern, and you lose portability.
• Running on a platform without fetch, and you have to handle custom platform detections and paths for custom compilation.
• Separate out the function even slightly from a few very restricted set of forms, and build tools and analysis tools can no longer analyze what is being executed.

https://github.com/tc39/proposal-import-reflection

Benefits

• Ergonomics: Provide a natural way to get a compiled Wasm module supported across platforms.
• Analysis: Allow code analysis to determine what Wasm modules are being executed using the same approaches that are applied to the JS module system.
• Tooling: Enables statically defined tooling approaches for Wasm module relocation and optimization.
• Security: Build security into the primitive from the start such that the reflected object can be associated with its original source URL so we know what we are executing later on.

https://github.com/tc39/proposal-import-reflection

JS Reflection

​

• Provide a common primitive for dynamic module instantiation workflows.
• Extend the same benefits of static analysis, tooling and security to JS module reflections in Compartments workflows.
• Do better than “module-eval”.

​

https://github.com/tc39/proposal-import-reflection

Host Hook

​

HostResolveModuleReflection(referencingScriptOrModule, specifier)�

• A host hook is required to support the WebAssembly module reflection due to spec layering requirements.
• We are hoping for progress from module blocks and compartments that will allow us to reference the JS module reflection API to another specification, as opposed to defining it in this proposal for now.
• For Stage 2, we are leaving it as host-defined through the hook.

​

https://github.com/tc39/proposal-import-reflection

Module cache key semantics

The intentions:

• Each import with any given fully qualified specifier returns the same result.
• This is identical to current behaviour in regular imports.

​

• Each reflected import for a given specifier refers to the same underlying asset as the symmetrical unreflected import.
• ie: you may not load assets differently based on if they are loaded because of a regular or reflected import

https://github.com/tc39/proposal-import-reflection

Open Questions

​

Most open questions come down to the interaction with module blocks and compartments.

• Exact host idempotence adjustments and module cache key semantics. While the expectations are clear and well-defined, how this will play out in spec text is yet to be seen.
• How to handle dynamic instantiation of JS reflections? (see the next session!)
• Will reflected modules support dynamic import instantiation via import(module) or not? Or perhaps only for one of JS and Wasm?

​

https://github.com/tc39/proposal-import-reflection

Questions from the queue?

https://github.com/tc39/proposal-import-reflection

Stage 2?

Initial spec text: https://tc39.es/proposal-import-reflection/

https://github.com/tc39/proposal-import-reflection