DaddyFrosty/yoga
1
0
Fork 0
Code Issues 96 Pull Requests 31 Actions Packages Projects Releases 33 Wiki Activity

Build WebAssembly with SINGLE_FILE=1 #1310

Closed
NickGerleman wants to merge 1 commits from export-D46884398 into main
pull from: export-D46884398
merge into: DaddyFrosty:main
Conversation 3 Commits 1 Files Changed 1 +2
NickGerleman commented 2023-06-21 14:26:03 -07:00 (Migrated from github.com)
Copy Link

Summary:
Emscripten normally compiles a binary into a .js file and a .wasm file. The .js file contains a shim to load the WebAssembly file for the target platform, along with passing some environment information to the underlying assembly.

Under Node this would use APIs like fs.readFile and its WebAssembly APIs to load the binary. In a browser, APIs like instantiateStreaming are used to start downloading and compiling the binary at the same time.

This format creates many, many, headaches, and manual bundler configuration. E.g. we must tell Webpack to treat WASM files as auxilary files instead of WebAssembly, cannot use Emscripten's loader directly, and would need to add more variants of the binary, since (or Node polyfills in the browser) -s ENVIRONMENT='web,node' emits code that looks like if (isNode) {require('fs')}.

This change makes us instead pack the WebAssembly as base64 inline with the JS loader. This adds a size penalty, and means we cannot start async compilation until the entire file is present, but should work out of the box when using different bundlers and configurations, and the size is small enough where it likely makes sense to inline into the bundle anyway.

There is a proposal for integration of WebAssembly and ES Modules that Node has experimental support for, and bundlers are veering towards supporting. It is the eventual solution we should target, but does not seem mature enough yet. E.g. WebPack does not support WebAssembly import objects, and will instead try to import each of the named imports as modules.

Reviewed By: rozele

Differential Revision: D46884398

Summary: Emscripten normally compiles a binary into a `.js` file and a `.wasm` file. The `.js` file contains a shim to load the WebAssembly file for the target platform, along with passing some environment information to the underlying assembly. Under Node this would use APIs like `fs.readFile` and its WebAssembly APIs to load the binary. In a browser, APIs like `instantiateStreaming` are used to start downloading and compiling the binary at the same time. This format creates many, many, headaches, and manual bundler configuration. E.g. we must tell Webpack to treat WASM files as auxilary files instead of WebAssembly, cannot use Emscripten's loader directly, and would need to add more variants of the binary, since (or Node polyfills in the browser) `-s ENVIRONMENT='web,node'` emits code that looks like `if (isNode) {require('fs')}`. This change makes us instead pack the WebAssembly as base64 inline with the JS loader. This adds a size penalty, and means we cannot start async compilation until the entire file is present, but should work out of the box when using different bundlers and configurations, and the size is small enough where it likely makes sense to inline into the bundle anyway. There is a [proposal for integration of WebAssembly and ES Modules](https://github.com/WebAssembly/esm-integration/tree/main/proposals/esm-integration) that Node has experimental support for, and bundlers are veering towards supporting. It is the eventual solution we should target, but does not seem mature enough yet. E.g. WebPack [does not support](https://github.com/webpack/webpack/issues/11893) WebAssembly import objects, and will instead try to import each of the named imports as modules. Reviewed By: rozele Differential Revision: D46884398
facebook-github-bot commented 2023-06-21 14:26:57 -07:00 (Migrated from github.com)
Copy Link

This pull request was exported from Phabricator. Differential Revision: D46884398

This pull request was **exported** from Phabricator. Differential Revision: [D46884398](https://www.internalfb.com/diff/D46884398)
facebook-github-bot commented 2023-06-21 15:08:36 -07:00 (Migrated from github.com)
Copy Link

This pull request was exported from Phabricator. Differential Revision: D46884398

This pull request was **exported** from Phabricator. Differential Revision: [D46884398](https://www.internalfb.com/diff/D46884398)
facebook-github-bot commented 2023-06-21 17:22:45 -07:00 (Migrated from github.com)
Copy Link

This pull request has been merged in facebook/yoga@b8a0240aaf.

This pull request has been merged in facebook/yoga@b8a0240aaf20175bec954cfd943c7df41332634c.

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
Algorithm
Build and Infrastructure
C#
C++ Enhancement
CLA Signed
Discussion
Documentation
Feature Request
Java
JavaScript
Merged
Question
Reverted
Shared with Meta
Applied via automation to indicate that an Issue or Pull Request has been shared with the team.
YogaKit
YogaLayout ViewGroup
bug
dependencies
Pull requests that update a dependency file
duplicate
enhancement
fb-exported
fh:direct-merge-enabled
invalid
ruby
Pull requests that update Ruby code
wontfix
No Label
CLA Signed
Merged
fb-exported
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
DaddyFrosty
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DaddyFrosty/yoga#1310
No description provided.
Delete Branch "export-D46884398"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?