Skip to content

Conversation

@schlawg
Copy link

@schlawg schlawg commented Mar 7, 2025

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.

  • EXPORT_ES6 linked javascripts will use Module['mainScriptUrlOrBlob'] if specified.
  • other logic should be unchanged
  • maybe a few bytes fatter after minification

@sbc100
Copy link
Collaborator

sbc100 commented Mar 7, 2025

Is this a duplicate of #23804?

#endif
worker = new Worker(pthreadMainJs, {{{ pthreadWorkerOptions }}});
#endif // EXPORT_ES6
var worker = new Worker(workerUrl, {{{ pthreadWorkerOptions }}});
Copy link
Collaborator

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,

Copy link
Author

@schlawg schlawg Mar 7, 2025

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

@schlawg
Copy link
Author

schlawg commented Mar 7, 2025

Is this a duplicate of #23804?

Probably. I looked at the title and commented on #23804, figuring it was blob urls only, then went straight to libpthread.js :)

If #23804 will support passing a string url for mainScriptUrlOrBlob under EXPORT_ES6, there's no need for this.

@schlawg
Copy link
Author

schlawg commented Mar 8, 2025

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.

@schlawg schlawg closed this Mar 8, 2025
@sbc100
Copy link
Collaborator

sbc100 commented Mar 10, 2025

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 new Worker(import.meta.url)? Is that because import.meta.url will include the content-hashed URL? Is the hash in the filename itself, or in the directory name?

Do you want the blunder to then re-write that line for you?

@schlawg
Copy link
Author

schlawg commented Mar 10, 2025

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 myTarget.js and myTarget.wasm through <url-base>/myTarget.1a2b3c4d.js and <url-base>/myTarget.5c6d7e8f.wasm where 1a2b3c4d and 5c6d7e8f are content hashes.

In emscripten EXPORT_ES6, importing <url-base>/myTarget.1a2b3c4d.js instantiates the main instance properly but our workers will fetch <url-base>/myTarget.js due to the special webpack consideration. We'd like a way to make workers fetch new Worker(import.meta.url, ...), or failing that, if mainScriptUrlOrBlob was respected in esm mode. either or both would be cool. We want to escape blunderers altogether.

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!

@sbc100
Copy link
Collaborator

sbc100 commented Mar 10, 2025

Thank you for the details. I think I have a better model how you need this to work.

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

Successfully merging this pull request may close these issues.

2 participants