import.meta.resolve

[kriskowal]

What is the Problem Being Solved?

The web and Node.js have arrived at a common understanding of import.meta.resolve. Specifically, that it synchronously produces a module specifier that, in the context of the calling module, produces a full module specifier suitable for import without loading much less executing the target module. Within mapped compartments, we can produce some but not all of the same invariants, because of compartment namespace isolation. We can produce an resolve behavior that is synchronous, given that it can close over the compartment map itself and doesn’t need to load anything to give correct answers.

Description of the Design

Create a utility for the Compartment Mapper that produces a web/node consistent importMetaHook that adds a resolve to import.meta for any module that utters import.meta. This makeImportMetaHook would close over a compartment map, compartment name, and module specifier and perform synchronous resolution at run time, such that import(x) in module Alice of compartment Alfa and import(import.meta.resolve(x)) in module Bob but also in compartment Alfa, will converge on the same namespace eventually.

Security Considerations

Preserving compartment import isolation should be inherent to the existing machinery. import.meta.resolve cannot produce a module specifier that import could use to reach a compartment that is not explicitly linked.

Scaling Considerations

A naïve implementation of the resolver could be linear in terms of pattern matching a compartment’s import and export patterns. We have not yet implemented pattern matching, just prefix matching. It’s likely that we would want to solve this problem after adding support for subpath patterns in package.json imports and exports. #2265

Test Plan

• module-relative module specifiers resolved to full specifiers in the context of one module and compartment
• package-relative module specifiers should converge regardless of which module of a single compartment
• cross-package module specifiers should work only if the dependent package is explicitly dependent on the dependency package, and should work consistently even between modules of the same package but different directory

Compatibility Considerations

Should be no concerns.

Upgrade Considerations

Likely no concerns.

[kriskowal]

There is no clear motivation yet for implementing this feature. Bundled software isn’t positioned to benefit from lazy loading or cobundled resource specifiers, at least not with this form of the feature. For assets, we need a clearer indication of dependency, either in-module or in-package. Like import xUrl from 'x.jpg' with { type: 'url' } or something similar would allow a bundler to capture the resource and provide a runtime-specific mechanism for revealing it for the produced string, likely a URL.