Summary:
X-link: https://github.com/facebook/react-native/pull/44792
Pull Request resolved: https://github.com/facebook/yoga/pull/1663
Fixing https://github.com/facebook/yoga/issues/1658. We had a problem where if a child had a different flex direction than its parent, and it also set a position as a percent, it would look at the wrong axis to evaluate the percent. What was happening was we were passing in the container's mainAxis size and crossAxis size to use to evaluate the position size if it was a percent. However, we matched these sizes with the main/cross axis of the child - which is wrong if the flex direction is different.
I changed it so that the function just takes in ownerWidth and ownerHeight then calls isRow to determine which one to use for the main/cross axis position. This reduces the ambiguity quite a bit imo.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58172416
fbshipit-source-id: eafd8069e03493fc56c41a76879d1ad9b7e9236d
Summary:
X-link: https://github.com/facebook/react-native/pull/44791
Pull Request resolved: https://github.com/facebook/yoga/pull/1662
This should fix https://github.com/facebook/yoga/issues/1657. Rather insidious bug but we had code like
```
// The total padding/border for a given axis does not depend on the direction
// so hardcoding LTR here to avoid piping direction to this function
return node->style().computeInlineStartPaddingAndBorder(
axis, Direction::LTR, widthSize) +
node->style().computeInlineEndPaddingAndBorder(
axis, Direction::LTR, widthSize);
```
That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58169843
fbshipit-source-id: 5b4854dddc019285076bd06955557edf73ef7ec5
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1648
Node made a breaking change in a security release for 18/20 where `spawn()` no longer loads `.bat` files by default. 69ffc6d50d. Execute command in shell.
Reviewed By: javache
Differential Revision: D56230965
fbshipit-source-id: 52e9bd8a76664bd07ea25b6355ac54fcb24cbb9a
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1645
Right now we publish Yoga by transforming in-place, and rewriting the entrypoint to point to the generated vanilla JavaScript.
It is nice to include the original source, e.g. so that users can use sourcemaps when debugging, but putting these files on top of each other has been causing problems, like https://github.com/facebook/yoga/issues/1637#issuecomment-2049099690
This changes the packaging step to instead put all the outputs into a "dist" folder, and point the package entrypoints there. We still include original source for sourcemap usage.
Reviewed By: yungsters
Differential Revision: D56093470
fbshipit-source-id: ecd52dddd9040294aae66747cf1fdf48c7f602e7
Summary:
X-link: https://github.com/facebook/react-native/pull/43752
Gentest tests started failing because Chrome changed behavior of overflowed align-content container. Spec says should fallback to "safe center", which is really just "start", instead of previous "center" behavior. This changes behavior accordingly.
There is one bit where I think we are doing the wrong thing wrt alignment of flex start vs start (which we don't support yet), but couldn't repro a failing chrome test.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D55617689
fbshipit-source-id: 08f23d198c75f2c2f51ccaa8795289e6e4a92cb8
Summary: Remove some outdated information and make sure that npmjs shows the builtin TypeScript typings (now that we no longer have clever resolution schemes).
Reviewed By: javache
Differential Revision: D54788636
fbshipit-source-id: 76e7663924189fd68ac62b27730f44213b13ad85
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1599
tsia. Had to add JS api support for set/get direction
Reviewed By: yungsters
Differential Revision: D54778992
fbshipit-source-id: 346152e1d61c80aa524b515e8b30a96fe32fe7c3
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1593
X-link: https://github.com/facebook/react-native/pull/43417
There was a bug where we did not position absolute nodes correctly if the static node had a different main/cross axis from the containing node. This fixes that. The change is somewhat complicated unfortunately but I tried to add sufficient comments to explain what is happening
Reviewed By: NickGerleman
Differential Revision: D54703955
fbshipit-source-id: 096c643f61d4f9bb3ee6278d675ebd69b57350d7
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1561
Back when I introduced the inline functions that would get the edge according to the writing direction I swapped some instances of `setLayoutPosition` which wrote to the flexStart edge erroneously. We should basically never read from some inline style and write to the flex edge. This changes them all to use the flex values.
Reviewed By: NickGerleman
Differential Revision: D52921401
fbshipit-source-id: 92b74d652018596134c91827806272ed7418ef6c
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1560
I added these when I was trying to debug the Facepile break removing the row-reverse errata caused. Yoga is doing the right thing, and the tests pass. We didn't have this specific coverage before, so add it.
Reviewed By: joevilches
Differential Revision: D52909633
fbshipit-source-id: d1e8f55bb534d76bd7dfdc46a1e1cc6f0a3ca211
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1558
X-link: https://github.com/facebook/react-native/pull/42318
AbsolutePositioning -> AbsolutePositioningCatchAll
A bit more clear. This errata is for various issues with positioning absolute nodes. There really isn't a clear description as to what specifically this enables/disables, so I just opted to say "catch all" to indicate that this controls various bugs
Reviewed By: NickGerleman
Differential Revision: D52820117
fbshipit-source-id: 80b77832baf65e68e57ca523c418422dd346ef0f
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1556
X-link: https://github.com/facebook/react-native/pull/42315
Since we aim to ship static to all users of yoga (not just XPR), we need to remove the errata that is gating most of the features. This should be a non breaking change. To ensure that, I added a new errata which, if on, will use the inner size of the containing node as the containing block. This is how it has been for a while and resolving this is risky and time consuming so for the time being we will stick with that.
Reviewed By: NickGerleman
Differential Revision: D52706161
fbshipit-source-id: 30a93f29cb0d97b20b2947eaa21f36cdc78c4961
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1549
X-link: https://github.com/facebook/react-native/pull/42253
This experimental feature is always false, and with the next diff I will be deleting the branch that actually calls into this. Separating this diff out to simplify the review process.
Reviewed By: NickGerleman
Differential Revision: D52705765
fbshipit-source-id: 705f4aa297eae730af9b44753eb01c9dec385dcf
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1547
X-link: https://github.com/facebook/react-native/pull/42251
Yoga has an odd behavior, where `start`/`end` edges under row-reverse are relative to flex-direction, instead of writing direction.
While Yoga doesn't actually document what this behavior is supposed to be, it goes against CK documentation, historic RN documentation, and the behavior valid on the web. It is also applied inconsistently (e.g. sometimes only on container, sometimes on child). It really is a bug, instead of an intended behavior.
We changed the default behavior for Yoga, but left the existing one behind an errata (so existing fbsource users got old behavior). We have previously seen this behavior show up in product code, including CK when running on FlexLayout.
`row-reverse` is surprisingly uncommon though:
1. Litho has <40 usages
2. RN has ~40 usages in `RKJSModules`,~30 in `arvr/js`, ~6 in `xplat/archon`
3. CK has ~80 usages
4. NT has ~40 usages
There are few enough, mostly simple components, that we can inspect through each of them, looking for signs they will hit the issue (at the potential chance of missing some).
CK accounts for 10/14 usages that I could tell would trigger the issue, since it only exposes start/end edge, and not left/right. It might make sense to make it preserve behavior instead, to reduce risk a bit.
FlexLayout is now separately powering Bloks, which wasn't surveyed, so I didn't touch CK behavior under Bloks.
There could also be other usages in other frameworks/bespoke usages, and this has implications for OSS users. But based on our own usage, of many, many components, this seems rare.
Changelog:
[General][Breaking] - Make `start/end` in styles always refer to writing direction
Reviewed By: pentiumao, joevilches
Differential Revision: D52698130
fbshipit-source-id: 2a9ac47e177469f30dc988d916b6c0ad95d53461
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1542
`YGNodeSetAlwaysFormContainingBlock` -> `YGNodeSetAlwaysFormsContainingBlock`
Started getting tasks telling me github CI was broken. Turns out I was just mispelling this.
Its not a big deal but we really should ensure that stuff will not land if it break github CI...not in our wheelhouse but it seems quite silly that this happens.
Also, a lot of the random files do not have auto complete or code checking which is why I didn't notice this to begin with.
Reviewed By: NickGerleman
Differential Revision: D52632257
fbshipit-source-id: 367ae5766ef9baecf55f7c227ff9fc8dece43af6
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1530
Yoga has a shortcut where if a min dimension and max dimension are the same, the value acts as a definite length.
I was curious how browsers handled this.
CSS 2.1 said:
> If the containing block's width depends on this element's width, then the resulting layout is undefined
This is superceded in the CSS box sizing spec. https://www.w3.org/TR/css-sizing-3/#sizing-values
> If, in a particular axis, the containing block’s size depends on the box’s size, see the relevant layout module for special rules on how to resolve percentages. Negative values are invalid.
And later:
https://www.w3.org/TR/css-sizing-3/#cyclic-percentage-contribution
> Sometimes the size of a percentage-sized box’s containing block depends on the intrinsic size contribution of the box itself, creating a cyclic dependency. When calculating the intrinsic size contribution of such a box (including any calculations for a content-based automatic minimum size), a percentage value that resolves against a size in the same axis as the intrinsic size contribution (a cyclic percentage size) is resolved specially:
> If the box is non-replaced, then the entire value of any max size property or preferred size property (width/max-width/height/max-height) specified as an expression containing a percentage (such as 10% or calc(10px + 0%)) that is cyclic is treated for the purpose of calculating the box’s intrinsic size contributions only as that property’s initial value. For example, given a box with width: calc(20px + 50%), its max-content contribution is calculated as if its width were auto. (The percentage is honored as usual, however, during the actual sizing of the box itself; see below.)
> Otherwise, the percentage is resolved against the containing block’s size. (The containing block’s size is not re-resolved based on the resulting size of the box; the contents might thus overflow or underflow the containing block).
So, for the purpose of sizing the parent, the child sized using a percentage does not contribute, but we should be sizing children based on that size.
Yoga does not really work like this right now, but gets the answer right answer for half of these tests.
Reviewed By: yungsters
Differential Revision: D52251601
fbshipit-source-id: 4978b90723130283b00e87bbf49795a4d209174c
Summary:
X-link: https://github.com/facebook/react-native/pull/41964
Pull Request resolved: https://github.com/facebook/yoga/pull/1524
D52087013 (#1513) fixed some issues, including where measuring under max-content or fit-content, align-content stretch would consume the entire available cross-dimensions, instead of only sizing to definite dimension, like the spec dicates.
I missed a case, where flexbox considers a container as having a definite cross-size if it is being stretched, even if it doesn't have a definite length.
https://www.w3.org/TR/css-flexbox-1/#definite-sizes
> 3. Once the cross size of a flex line has been determined, items in auto-sized flex containers are also considered definite for the purpose of layout;
> 1. If a single-line flex container has a definite cross size, the outer cross size of any stretched flex items is the flex container’s inner cross size (clamped to the flex item’s min and max cross size) and is considered definite.
We handle `align-items: stretch` of a flex container after cross-size determination by laying out the child under stretch-fit (previously YGMeasureModeExactly) constraint. This checks that case, and sizing the line container to specified cross-dim if we are told to stretch to it.
We could probably afford to merge this a bit with later with what is currently step 9, where we end up redoing some of this same math.
Reviewed By: yungsters
Differential Revision: D52234980
fbshipit-source-id: 475773a352fd01f63a4b21e93a55519726dc0da7
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1513
X-link: https://github.com/facebook/react-native/pull/41916
Fixes https://github.com/facebook/yoga/issues/1300
Fixes https://github.com/facebook/yoga/issues/1008
This fixes a smattering of issues related to both sizing and aligment of multi-line-containers:
1. We were previously incorrectly bounding the size of each flex line to the min/max of the entire container.
2. Per-line leads were sometimes incorrectly contributing to alignment within the line
3. The cross dim size used for multi-line alignment is not correct, or correctly clamped. If the available size comes from a max constraint, that was incorrectly used instead of a definite size, or size of content. Leads were entirely skipped for min constraint.
Need to test how breaking this is, to see if it might need to go behind an errata.
See related PRs:
1. https://github.com/facebook/yoga/pull/1491
2. https://github.com/facebook/yoga/pull/1493
3. https://github.com/facebook/yoga/pull/1013
Changelog:
[General][Fixed] - Fix Yoga sizing and alignment issues with multi-line containers
Reviewed By: joevilches
Differential Revision: D52087013
fbshipit-source-id: 8d95ad17e58c1fec1cceab9756413d0b3bd4cd8f
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1503
This diff makes it so that our driver will sign all of the generated files to help ensure that they are not edited by hand. Next I will add CI to actually verify the signature
Reviewed By: NickGerleman
Differential Revision: D51966201
fbshipit-source-id: f7e3f4fde1c98832212a448b2dcc8e21be0560c4
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1501
Now that we have `gentest-driver.ts` we can delete the ruby gentest. I also regened all of the tests that have a comment with the wrong file name for where it was generated.
Reviewed By: yungsters, NickGerleman
Differential Revision: D51956567
fbshipit-source-id: d389492e54711cf161dff9e649396cc40f1e5073
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1498
The only instance of ruby in this repository is `gentest.rb` used to generate test cases from html fixtures. This is quite annoying as ruby is not the most popular compared to something like Node and it does not integrate into the rest of our stack. I changed this to use Node.js instead. Instead of `watir` we now use `selenium-webdriver`. `watir` is backed by Selenium so I do not expect anything to change.
Next commits will add command line options, clean up gentest.rb and its references, and change the README
allow-large-files
Reviewed By: yungsters, NickGerleman
Differential Revision: D51874433
fbshipit-source-id: ef8588d48aa7f8b720b57df08738bbd01e9e74a3
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1500
Inspired by the frequent usage of Expo snacks to run RN, to repro Yoga issues, this replaces the Playground port with a new ground up Playground UI. This UI right now is pretty simple, with a JSX editor which creates a Yoga tree, which is then rendered using the WebAssembly variant of Yoga.
There are a lot of ways we can continue to improve this, but this merges the foundation. Subjectively, I find this more useful as a tool to play with Yoga behavior than the GUI.
This also replaces some of the bits of the homepage, and adds a playground entrypoint (though it's pretty identical to the one I've been testing on the home page).
Reviewed By: yungsters
Differential Revision: D51963201
fbshipit-source-id: 1265cb1784151b685686e189d47ecd42cbacdf8f
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1506
In order to build the website, you must build a Yoga binary. This usually requires installing native toolchains.
We have warning messages for these right now, but an even better solution is to just manage the dependencies ourselves. This does that, bringing in specific CMake and Ninja binaries from NPM, and caching a local copy of Emscripten during the build.
A downside is that the CMake packages are chunky, so we add 130MB to node_modules (for a repo total around 350MB). This also delays acquiring Emscripten (which is even chunkier) in CI builds until it is needed, and I added some caching for it as well.
The upside of JS users being able to run and test (inc the website) without installing and managing their own versions of toolchains is a real time-saver though, and is probably worth it.
allow-large-files
Reviewed By: yungsters
Differential Revision: D52013026
fbshipit-source-id: 3d307f751463a21c5e5d5b98b8e9e63db9d3d52e
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1488
These were disabled when they were written because they were broken. The recent changes made them pass now so lets enable them. I also added another test that is already passing
Reviewed By: NickGerleman
Differential Revision: D51404875
fbshipit-source-id: ed10004968b871c1d033640d75138f00afc15968
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1490
X-link: https://github.com/facebook/react-native/pull/41692
In the previous diffs I fixed problems with justifying absolute nodes. The same issues plague aligning so I fixed them in the same way. Added tests that were failing before but now passing
Reviewed By: NickGerleman
Differential Revision: D51404489
fbshipit-source-id: 604495d651eb67cfdcca40df9d8d3a125c5741a8
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1487
X-link: https://github.com/facebook/react-native/pull/41691
The code here was just wrong. I changed it to be the same logic as the Justify:FlexStart case, but with the flex end sides. Then I get the position for the opposite edge since we need to write to flex start side.
Reviewed By: NickGerleman
Differential Revision: D51383792
fbshipit-source-id: 372835a44edff361dbd84dd92ff9f2ec844b9f9c
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1489
X-link: https://github.com/facebook/react-native/pull/41690
Centering involves centering the margin box in the content box of the parent, and then getting the distance from the flex start edge of the parent to the child
Reviewed By: NickGerleman
Differential Revision: D51383625
fbshipit-source-id: 6bbbace95689ef39c35303bea4b99505952df457
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1485
X-link: https://github.com/facebook/react-native/pull/41686
The size of the containing block is the size of the padding box of the containing node for absolute nodes. We were looking at `containingNode->getLayout().measuredDimension(Dimension::Width)` which is the border box. So we need to subtract the border from this.
Added a test that was failing before this change as well
Reviewed By: NickGerleman
Differential Revision: D51330526
fbshipit-source-id: adc448dfb71b54f1bbed0d9d61c5553bda4b106c
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1482
X-link: https://github.com/facebook/react-native/pull/41685
This is the final step (that I know of) to get the core features of static working. Here we turn on all of the tests and pass down the correct owner size for the call to `calculateLayoutInternal` that is in `layoutAbsoluteChild`
Reviewed By: NickGerleman
Differential Revision: D51293606
fbshipit-source-id: 972259e7ebecb19b55aef2ef866bd7cb57aaf0ca
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1481
X-link: https://github.com/facebook/react-native/pull/41684
Absolute nodes can be laid out by themselves and do not have to care about what is happening to their siblings. Because of this we can make `positionAbsoluteChild` the sole place where we handle this logic. Right now that is scattered around algorithm with many `if (child is absolute)` cases everywhere. This makes implementing position static a lot harder since we are relying on the CB to do all this work, not the parent.
With this change the only time we set position for an absolute node and it matter (i.e. not overwritten) is in `positionAbsoluteChild`
Reviewed By: NickGerleman
Differential Revision: D51290723
fbshipit-source-id: 405d81b1d28826cbb0323dc117c406a44d381dff
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1496
Gentest code has a problem where we try to apply a border in our test when the web browser is not actually adding one. This happens when we do something like `border-top: 10px`. This will actually set the style of the border to `initial` which is just `none`, so nothing renders. This is causing at least 1 test to pass when it actually fails.
I changed it so we ignore setting this value if the style is one of these values. I then re-ran the gentest code and excluded the now failing test (which gets fixed in my static stack).
Reviewed By: NickGerleman
Differential Revision: D51831754
fbshipit-source-id: a325e4a42b2d7cd6f19efc6cd5a2445574467fb7
Summary:
X-link: https://github.com/facebook/react-native/pull/41480
Pull Request resolved: https://github.com/facebook/yoga/pull/1469
The previous version of static didn't do anything inside of Yoga. Now that we're making it do something, this changes the default back to relative so that users with no errata set don't see their deafult styles changing.
Reviewed By: joevilches
Differential Revision: D51182955
fbshipit-source-id: c0ea357694e1367fb6786f1907dfff784b19a4bc
Summary:
X-link: https://github.com/facebook/react-native/pull/41423
Pull Request resolved: https://github.com/facebook/yoga/pull/1466
Right now Yoga's main branch says it's 2.0.0, and RN's dirsync says its 1.14.0, but the code is really closer to what will be Yoga 3.0.0.
This changes trunk builds to "0.0.0" for clarity, which will be assigned a real version number the first time publishing a new Yoga branch.
This is separately a good practice to prevent the chance of accidental publishes causing damage.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51236778
fbshipit-source-id: 06cac89bcca1c707ce5c00f9c346f627eef6b4bc
Summary:
X-link: https://github.com/facebook/react-native/pull/41420
Pull Request resolved: https://github.com/facebook/yoga/pull/1465https://yogalayout.com now redirects to https://yogalayout.dev
This replaces references to "yogalayout.com" with "yogalayout.dev", the same website, with a new domain. This includes:
1. Code comments
2. Yoga website config (publish action CNAME, Docusaurus config)
3. Documentation URLs in Yoga packages
Changelog:
[General][Fixed] - "yogalayout.com" to "yogalayout.dev"
Reviewed By: christophpurrer
Differential Revision: D51229587
fbshipit-source-id: b1c336a52aab5e02565071b61430d5435381dc0a
Summary:
X-link: https://github.com/facebook/react-native/pull/41293
Pull Request resolved: https://github.com/facebook/yoga/pull/1446
NickGerleman pointed out that my recent changes to fix the slew of row-reverse problems in Yoga actually ended up regressing some parts. Specifically, absolute children of row-reverse containers would have their insets set to the wrong side. So if you set left: 10 it would apply it to the right.
Turns out, in `layoutAbsoluteChild` there were cases where we were applying inlineStart/End values to the flexStart/End edge, which can never be right. So I changed the values to also be flexStart/End as the fix here.
Reviewed By: NickGerleman
Differential Revision: D50945475
fbshipit-source-id: 290de06dcc04e8e644a3a32c127af12fdabb2f75
Summary:
`child.offsetLeft/Top` calculates the offset from child to its nearest positioned ancestor, not its direct parent. These are often the same and have not mattered in the past since we have not supported position static. Since are are in the process of supporting that, we would like our tests to be usable so this adjusts the gentest methodology to only speak the same language as Yoga - that is left/top are always relative to direct parents.
It works by using `getBoundingClientRect().left/top` instead. Then we pass that down to children and subtract it from the childs `getBoundingClientRect()` to get the position relative to the parent. Note we have to round the final result as `child.offsetLeft/Top` is rounded.
Reviewed By: NickGerleman
Differential Revision: D51053629
fbshipit-source-id: 8809588d12953565228ae50fdf38197213c46182
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1447
Just ran
```
ruby xplat/yoga/gentest/gentest.rb
```
It seems that D50453324 changed a bunch of the import directories in these test files but for some reason it did not get picked up for this test. As a result we are seeing failing github checks like https://github.com/facebook/yoga/actions/runs/6738747977/job/18318958442. Should be good now.
Reviewed By: yungsters
Differential Revision: D50951161
fbshipit-source-id: a2472022782f64f840a64ed991f5f35c3ef556dc
Summary:
Fixes https://github.com/facebook/yoga/issues/1417
This dramatically simplifies the matrix of Node vs web, ASM vs WASM, sync vs async compilation, or CommonJS vs ES Modules. We have one variant, using wasm, with ESModule top-level await to do async compilation. Web/node share the same binary, and we base64 encode the WASM into a wrapper JS file for compatibility with Node and bundlers.
This has some downsides, like requiring an environment with top level await, but also has upsides, like a consistent, sync looking API compatible with older Yoga, and mitigating TypeScript issues with package exports and typings resolution.
As part of this work I also removed `ts-node` from the toolchain (at the cost of a couple of config files needing to be vanilla JS).
Pull Request resolved: https://github.com/facebook/yoga/pull/1433
Test Plan:
1. `yarn test`
2. `yarn lint`
3. `yarn tsc`
4. `yarn benchmark`
5. `yarn build` website-next
6. `yarn lint` website-next
7. Locally test website-next
8. Examine package artifact created by GitHub
9. All Automation passes
Reviewed By: yungsters
Differential Revision: D50453324
Pulled By: NickGerleman
fbshipit-source-id: fe1192acc69e57fa69a1ff056dd7b5844d2198d5
