Support for import.meta.resolve(...)

[lgarron]

From #2508 (comment), as an alternative to:

• WebWorker support? #312
• Include new URL("...", import.meta.url) references in the import graph. #2470
• Batch of several breaking changes #2508 (comment)

@evanw: If these breaking changes are too much to land in the short term, could I ask/suggest support for import.meta.resolve(...) support as an alternative to new URL(..., import.meta.url)? This is becoming a fairly urgent point of friction with esbuild for any libraries with worker code, because esbuild does not have any out-of-the-box compatibility overlap with other major bundlers/browsers when it comes to such relative path calculations.

Since the time this PR was originally created, import.meta.resolve(...) has now been available in all modern browsers for several months. Unfortunately, code published using import.meta.resolve(...) (e.g. npm packages) will break when used in projects that use esbuild, unless esbuild recognizes the imported path argument as a node in the import graph.

• Chrome
• Firefox
• Safari

As long as the path argument is handled as part of the import graph, it can be:

• emitted as import.meta.resolve(...) for esnext targets, or

• emitted as new URL(..., import.meta.url).href for older ESM targets.

  • (Or into direct dynamic imports, in some cases.)

I'd be happy to send an updated version of this PR if that would help.

[lgarron]

• for esnext targets

One wrinkle is that import.meta.resolve(...) is actually not part of ECMAScript, but part of the HTML spec:

• https://html.spec.whatwg.org/#hostgetimportmetaproperties
• Add import.meta.resolve() whatwg/html#5572

It is clearly a feature "from 2022", but it isn't formally part of es2022, nor es2023. ECMA-262 defines import.meta but not is fields.

That said, it is already fully supported by Chrome, Firefox, Safari, node (but async, behind flag), and deno, so it is definitely no longer an "experimental" new feature at this point.

I'd advocate for:

• Emitting it in esnext, es2023 (once that is implemented as a target), and an import-meta-resolve support flag.
• Otherwise, transpiling to new URL(..., import.meta.url).href for targets that support import.meta.

[lgarron]

Since the time this PR was originally created, import.meta.resolve(...) has now been available in all modern browsers for several months

It seems I was mistaken about this at the time — Safari required the feature to be enabled manually from the developer menu. However, Safari 16.4 is now out, and supports this directly by default. I've thoroughly tested that all modern browsers now support import.meta.resolve(…) reliably, which is really good news for library authors as soon as bundlers can support it.

[lgarron]

@evanw: This is becoming an urgent point of incompatibility for several of my apps and libraries, as it is currently impossible to publish ESM libraries (using widely compatible syntax & APIs) that use web workers and/or WASM while also remaining sufficiently compatible with bundlers. Could I ask for an indication whether you would support adding this feature (or #795) — in particular, whether you would accept a pull request to implement it?¹

I would be happy to invest a lot of effort to make this happen if you would be amenable.

For more context:

• Firefox 113 just released and Firefox 114 is now set to launch with dom.workers.modules.enabled in less than a month. At that point, I intend to remove a variety of fallback workarounds (which currently triple the size of app code sent over the wire to Firefox) and rely on pure ESM web workers. We need esbuild to support import.meta.resolve(…)¹ out of the box, or else it is certain that we will break apps that use our libraries with bundlers.
• I have started using WASM, but I have to inline entire WASM files as base64 to get around this issue. I would like to avoid such workarounds, in favor of publishing actual WASM files as part of libraries.

Footnotes

1. Or land an updated version of https://github.com/evanw/esbuild/pull/2470 or the implementation of https://github.com/evanw/esbuild/pull/2508 ↩ ↩²

[Jason3S]

@lgarron,

This is a bit of an old issue, but have you considered using import-meta-resolve?

[lgarron]

@lgarron,

This is a bit of an old issue, but have you considered using import-meta-resolve?

I don't really follow. import.meta.resolve(…) is natively supported in all browsers and runtimes at this point (Chromium-based browsers, Firefox, Safari, node, deno, bun).

However, esbuild currently does not preserve the resolution of import.meta.resolve(…) when bundling code, because it doesn't include the argument in the import graph. That's the functionality I'd love to see in esbuild.

(I'd still be happy to finish up my branch for it if I can get an indication from @evanw that a pull request would be welcome.)