-
Notifications
You must be signed in to change notification settings - Fork 3.4k
respect mainScriptUrlOrBlob for esm targets #23859
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
Conversation
|
Is this a duplicate of #23804? |
src/lib/libpthread.js
Outdated
| #endif | ||
| worker = new Worker(pthreadMainJs, {{{ pthreadWorkerOptions }}}); | ||
| #endif // EXPORT_ES6 | ||
| var worker = new Worker(workerUrl, {{{ pthreadWorkerOptions }}}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sadly we cannot use a variable for the first argument of the new Worker.. it needs to be a literal new URL in order for the bundlers to pick it up correctly. See the commend up on line 427,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i reckon webpack would still handle the full new Worker(new URL(...)) shebang in a ternary expression
|
The only reason we need mainScriptUrlOrBlob is because new Worker(import.meta.url) is not used. Some kind of -sES6_IMPORT_META flag to sidestep the bundler complication would actually be perfect. |
Can you explain a little more about what your ideal solution would be? Do you want Do you want the blunder to then re-write that line for you? |
|
Our build system makes content hashed symlinks that point back to their sources for versioning and CDN caching. Ideally, clients would access the hypothetical emscriptem artifacts In emscripten EXPORT_ES6, importing At present, we cache bust emscripten assets using a path component that changes on every restart or asset deploy. It works but our users end up unnecessarily re-downloading large files quite often because of that blunt instrument. Sorry if this is TMI and thanks for asking! |
|
Thank you for the details. I think I have a better model how you need this to work. |
we would like to serve emscripten javascripts from a content hashed url, but the EXPORT_ES6 code path always bootstraps pthreads with
new Worker(new URL('{{{ TARGET_JS_NAME }}}', import.meta.url), ...). if it's possible to support mainScriptUrlOrBlob for esm, that would make our day.