Nick Gerleman 106ce90436 Build WebAssembly with SINGLE_FILE=1 (#1310)
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1310

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

fbshipit-source-id: 8c4b9de2e7b5f1ebef90b76f6bc301d1edf61c51
2023-06-21 15:07:04 -07:00
2023-06-08 02:23:48 -07:00
2023-06-08 02:23:48 -07:00
2023-06-13 12:40:09 -07:00
2022-12-29 10:27:00 -08:00
2023-01-16 04:16:07 -08:00
2019-01-08 12:50:41 -08:00
2017-05-27 09:12:22 -07:00
2023-05-04 11:30:01 -07:00
2021-08-13 08:24:14 -07:00
2023-05-04 11:30:01 -07:00
2023-01-16 04:16:07 -08:00
2016-12-07 17:41:50 +00:00

Yoga Support Ukraine CocoaPods npm Maven Central

Yoga is an embeddable and performant flexbox layout engine with bindings for multiple languages.

Building

Yoga's main implementation targets C++ 14 with accompanying build logic in CMake. A wrapper is provided to build the main library and run unit tests.

./unit_tests <Debug|Release>

While not required, this script will use ninja if it is installed for faster builds.

Yoga is additionally part of the vcpkg collection of ports maintained by Microsoft and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

Adding Tests

Many of Yoga's tests are automatically generated, using HTML fixtures describing node structure. These are rendered in Chrome to generate an expected layout result for the tree. New fixtures can be added to gentest/fixtures.

<div id="my_test" style="width: 100px; height: 100px; align-items: center;">
  <div style="width: 50px; height: 50px;"></div>
</div>

To generate new tests from added fixtures:

  1. Run bundle install in the gentest directory to install dependencies of the test generator.
  2. Run ruby gentest.rb in the gentest directory.

Debugging

Yoga provides a VSCode "launch.json" configuration which allows debugging unit tests. Simply add your breakpoints, and run "Debug C++ Unit tests (lldb)" (or "Debug C++ Unit tests (vsdbg)" on Windows).

Description
Yoga is an embeddable layout engine targeting web standards.
Readme MIT 37 MiB
Yoga 3.2.1 Latest
2024-12-12 17:41:47 -08:00
Languages
C++ 46.4%
Java 25.2%
TypeScript 23.1%
HTML 2.6%
JavaScript 1%
Other 1.6%