-
Notifications
You must be signed in to change notification settings - Fork 12k
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
Angular should *not* disable Webpack's import.meta.url parsing (for WebAssembly files, at least) #24617
Comments
Karma ES6 support
The Angular CLI also offers the possibility to use an Esbuild instead of a Webpack based builder which supports ESM fully. This is still experimental and only support If you wish to enable/disable one of these above mentioned Webpack specific features, a custom Webpack configuration would be mandatory. |
Thank you for the really detailed response! This problem basically ate my entire day, so I really appreciate the explanation. But in particular if using esbuild will solve the problem, I will gladly use esbuild, and suffer the 60% speedup in compile time. If a custom webpack config is what's necessary, and esbuild is the future anyway, then this is an acceptable solution. |
Another suggestion - since (if I'm not mistaken) Angular does allow webpack to bundle workers accessed via |
While Webpack can bundle web workers when using |
Closing as per above. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Command
build
Is this a regression?
The previous version in which this bug was not present was
No response
Description
Actually, Angular should just make up its h*cking mind (see #24616).
Currently, its mysterious and ephemeral built-in webpack configuration disables module.parser.javascript.url, so assets imported with
new URL(..., import.meta.url)
do not get packaged by default.Okay, that's fine, if you're into that kind of thing, but at the same time it keeps module.parser.java.importmeta enabled, leading webpack to output entirely useless
file://
URLs instead of doing any packaging.End result is that you just can't use any ES6 module (such as anything compiled with Emscripten's
EXPORT_ES6
option) that tries to load some possibly really important asset, like, say, a WebAssembly file. You are damned if you do and damned if you don't! If you do what is suggested in #22351 and try to use theassets
option, the actually generated code will not reference this asset becauseimport.meta.url
got rewritten to some path on your build filesystem.But if you then disable
module.parser.java.importmeta
manually in a custom webpack config, then you end up withimport.meta.url
in the output code, which utterly breaks testing with karma (since karma does not do ES6 modules, because that's like not groovy, man) and of course also any possibility of targeting a non-ES6-aware browser.This is the opposite of webpack's perfectly good and sane defaults. A reasonable workaround is to create a custom webpack config which enables
module.parser.java.url
, like this:Minimal Reproduction
From an Angular app, try to load an ES6 module (like https://www.npmjs.com/package/soundswallower?activeTab=explore) that has an accompanying WASM file, or any kind of asset that is loaded with
new URL(..., import.meta.url)
. The relevant code output by Emscripten is:Exception or Error
No response
Your Environment
Anything else relevant?
No response
The text was updated successfully, but these errors were encountered: