Emit bundler-friendly URL locators #14135
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sbc100
reviewed
May 10, 2021
|
|
RReverser
force-pushed
the
bundler-friendly
branch
from
5232c1d to
ada767e
Compare
sbc100
reviewed
May 10, 2021
This PR changes loading of main Wasm binary as well as helper Worker used by PThread integration to use a URL expression that can be both used directly by browsers as well as statically detected by bundlers like Webpack. The main caveats are: 1. Emscripten is very configurable, so some of the new conditions might look odd but are necessary to keep backward compatibility and allow overriding bundler-friendly URL with a custom one during runtime. 2. None of Closure, our fork of Terser, and `eval` (which is used by Emscripten's JS library preprocessing) support `import.meta` expressions without more work. While Closure seems to have _just_ implemented such support, and it wouldn't be too hard to add it to our Terser too, `eval` usage would still require a string replacement before execution (or complete revamp). To keep implementation simple, for now I went with just string replacement that covers all tools - this way, we replace `import.meta` -> `EMSCRIPTEN$IMPORT$META` only once per library when JS is added before any of this tooling is executed, and then replace back after everything is done right before the final emit. We might want to revisit this in future, but for now this works well and covers all the tooling incompatibilities together. 3. Webpack assumes that all modules are strict mode, so I updated `worker.js` correspondingly to avoid usages of global `this` (which is `undefined` in strict mode and breaks in bundled code) and instead using `self`; I've also updated the Node.js adapter code to satisfy strict requirements too and to be a bit simpler. 4. This won't work in Node.js, since it's not compatible with `EXPORT_ES6` in general yet. 5. I've only updated places for loading main Wasm binary and PThread code. This should cover majority of use-cases, but other external files like side modules, proxy-to-pthread, proxy-to-worker, external memory loading etc. are not covered by this PR and need to be updated separately if someone wants them to work with bundlers out of the box too. Fixes #13571.
RReverser
force-pushed
the
bundler-friendly
branch
from
9b22a59 to
43c6f23
Compare
sbc100
approved these changes
May 10, 2021
|
PR description could use an update now that (3) landed separately. Otherwise feel free to land. |
Updated! |
RReverser
added a commit
that referenced
this pull request
May 11, 2021
During review of #14135 some of the changes made TARGET_JS_NAME to be a relative path instead of a basename. This way, when someone specified `-pthread -o out.js`, it worked fine, but if someone used `-pthread -o nested/dir/out.js` then the `nested/dir/out.worker.js` would have a reference to `./nested/dir/out.js` not to `./out.js` as it should for a file alongside it.
RReverser
added a commit
that referenced
this pull request
May 20, 2021
`Module['locateFile']` needs to be checked even in `EXPORT_ES6` mode. In #14135 I did this for `new Worker`, but not for Wasm binary locator, so it broke existing usages of EXPORT_ES6 + custom `locateFile` function.
sbc100
pushed a commit
that referenced
this pull request
May 21, 2021
`Module['locateFile']` needs to be checked even in `EXPORT_ES6` mode. In #14135 I did this for `new Worker`, but not for Wasm binary locator, so it broke existing usages of EXPORT_ES6 + custom `locateFile` function.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR changes loading of main Wasm binary as well as helper Worker used by PThread integration to use a URL expression that can be both used directly by browsers as well as statically detected by bundlers like Webpack.
The main caveats are:
eval(which is used by Emscripten's JS library preprocessing) supportimport.metaexpressions without more work. While Closure seems to have just implemented such support, and it wouldn't be too hard to add it to our Terser too,evalusage would still require a string replacement before execution (or complete revamp).To keep implementation simple, for now I went with just string replacement that covers all tools - this way, we replace
import.meta->EMSCRIPTEN$IMPORT$METAonly once when JS is added before any of this tooling is executed, and then replace back after everything is done right before the final emit.We might want to revisit this in future, but for now this works well and covers all the tooling incompatibilities together.
EXPORT_ES6in general yet.Fixes #13571.