Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
lgarron opened this issue Jan 24, 2023 · 5 comments
Open

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

lgarron opened this issue Jan 24, 2023 · 5 comments

Comments

@lgarron
Copy link
Contributor

lgarron commented Jan 24, 2023

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

@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.

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 lgarron changed the title Support for import.meta.url(...) Support for import.meta.resolve(...) Jan 24, 2023
lgarron added a commit to lgarron/esbuild that referenced this issue Jan 24, 2023
`make js-api-tests` fails to include the worker file in the build.

This is an adaptation of evanw#2470 , for evanw#2866
@lgarron
Copy link
Contributor Author

lgarron commented Jan 25, 2023

  • for esnext targets

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

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
Copy link
Contributor Author

lgarron commented Apr 2, 2023

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
Copy link
Contributor Author

lgarron commented May 9, 2023

@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?1

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(…)1 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 2

lgarron added a commit to cubing/cdn.cubing.net that referenced this issue Sep 8, 2023
I would prefer to avoid hardcoding any paths except those that are published as CDN entry points, but `esbuild` still doesn't support `new URL(…, import.meta.url)` (evanw/esbuild#312) or `import.meta.resolve(…)` (evanw/esbuild#2866).
lgarron added a commit to cubing/cdn.cubing.net that referenced this issue Sep 8, 2023
…irefox.

Users of the CDN can't prevent the worker failure messages, so they are just noise (and a potential slowdown). This hardcodes the entry file path where the instantiator (which reliably ends up in a chunk for us) expects it: https://github.com/cubing/cubing.js/blob/4afc6d727549aadc1e82abf52d531565953e7a9a/src/cubing/search/worker-workarounds/index.ts#L11

I would prefer to avoid hardcoding any paths except those that are published as CDN entry points, but `esbuild` still doesn't support `new URL(…, import.meta.url)` (evanw/esbuild#312) or `import.meta.resolve(…)` (evanw/esbuild#2866).
lgarron added a commit to lgarron/esbuild that referenced this issue Oct 13, 2023
`make js-api-tests` fails to include the worker file in the build.

This is an adaptation of evanw#2470 , for evanw#2866
@Jason3S
Copy link

Jason3S commented Apr 23, 2024

@lgarron,

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

@lgarron
Copy link
Contributor Author

lgarron commented Apr 23, 2024

@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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants