Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1717
CocoaPods is EOL (though we will still support it for a while), and Yoga has SPM support, so let's add a badge!
SPM does not have a central registry (it instead uses our Git branch), so there isn't a badge to show the current vesion, we instead just mention that we support it, which is what I found other projects do.
Reviewed By: nmn
Differential Revision: D63845470
fbshipit-source-id: d033700fa04b8d708890b1c51d0a37fab8251a43
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1521
I linked the forked version of yarn when in reality it should be yarn classic
Reviewed By: NickGerleman
Differential Revision: D52215925
fbshipit-source-id: 5d5800d162f2cc250fcf54151de0de87a427abc2
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1502
We should change this if we are moving away from using Ruby
Reviewed By: yungsters, NickGerleman
Differential Revision: D51957351
fbshipit-source-id: fddb0b3348db2b93c661c919a61150c81906a61a
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1382
X-link: https://github.com/facebook/react-native/pull/39437
Have been running into places where C++ 20 makes life easier for use like `std::bit_cast` (that one is easy to polyfill), in-class member initializer support for bitfields, designated initializers, defaulted comparison operator, concepts instead of SFINAE, and probably more.
Our other infra is in the process of making this jump, or already has. This tests it out everywhere, across the various reference builds, to see if we have any issues.
This is a bit more aggressive than I had previously communicated, but n - 1 is going to be a better long term place than n - 2.
If we wanted to use `std::bit_cast` we would need one of:
1. GCC 11+ (~2.5 years old)
1. Clang 14 (~2.5 years old)
1. VS 16.11 (~2 years old)
For mobile this means:
1. NDK 26 (still in Beta 😭)
1. XCode 14.3.0 (~6 months old)
https://en.cppreference.com/w/cpp/compiler_support/20
That isn't quite doable yet, but we can start taking advantage of language features in the meantime. More of these will be supported in older toolchains.
Anyone needing support for older C++ versions can lag behind on more recent changes. E.g. Yoga 2.0 supports C++ 14.
bypass-github-export-checks
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D49261607
fbshipit-source-id: ceb06eac20dfe93352d7b796d6847a7314069cf3
Summary: We deprecated this as part of the Yoga 2.0 release. The last version is still present as part of the release-v2.0 branch, and was still published, but we are not carrying the code forward. This removes it.
Reviewed By: mdvacca
Differential Revision: D47136781
fbshipit-source-id: ac60939efb2372db04e33ed26456bad2f3b5852b
Summary:
X-link: https://github.com/facebook/react-native/pull/38303
Pull Request resolved: https://github.com/facebook/yoga/pull/1327
This bumps Yoga to C++ 17 for a few reasons:
1. New versions of C++ may introduce behavior changes (e.g. evaluation order) and deprecations. Keeping the version closer to the version of large users helps avoid that.
2. C++ 17 unblocks some new bits I have wanted to use at times, like `std::optional`, `std::variant`, `if constexpr`, `[[nodiscard]]`.
3. There are already changes in C++ 20 that would be directly useful to Yoga, like `std::bit_cast` to avoid `memcpy` style type punning.
There has been some contention around C++ versions before, but by the time the next stable version of Yoga is out, it will have been more than 6 years (~2 C++ versions) since a stable version of Clang/LLVM with C++ 17 support. I would not like to go back further than n-2.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D47383922
fbshipit-source-id: eb95d4853f2168b68d6df5fddb797236eac55870
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1217
This updates the CMake build present for being able to share options, fixing up flags, etc. A GTest build is added as well, along with a script and VSCode debug target so that OSS contributors can very easily run and debug tests on any OS.
Note that this isn't completely done (need to revise Windows, Mac, documentation), but should be finished enough otherwise for review.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D42406686
fbshipit-source-id: 95e7ba5e4751c496a171785490e85cf0097fa839
Summary:
This change starts adding more coverage to GitHub Actions. Existing workflows are split up to be per-platform, and stale scripts, etc are removed.
We are currently limited a bit by issues with the build itself, but this still adds a good bit of coverage that readily works, and adds places to inject more.
Another option would have been to move these to CircleCI where we have more credits, or used docker images instead of manual setup steps. etc, The Yoga build and number of changes is very light though, so we don't really need the complexity yet.
Some TODOs:
1. Fix the Apple Builds (pod lint and pod install return errors seen by the community)
2. Add working Android UTs
3. Add C++ UTs
4. Add Apple Publish
5. Add version stamping
Changelog:
[Internal][Added] - Start Adding Yoga GitHub Actions
Pull Request resolved: https://github.com/facebook/yoga/pull/1165
Reviewed By: cortinico
Differential Revision: D40386426
Pulled By: NickGerleman
fbshipit-source-id: c540dd25bfec6ac8c05e461c1236ef7fe6cb8598
Summary:
Yoga is available as a port in VCPKG , documenting the install process here will help users get started by providing a single set of commands to build yoga, ready to be included in their projects.
VCPKG is a C++ library manager that simplifies installation for yoga and other project dependencies, we also test whether our library ports build in various configurations (dynamic, static) on various platforms (OSX, Linux, Windows: x86, x64, UWP, ARM) to keep a wide coverage for users.
I'm a maintainer for vcpkg, and here is what the port script looks like. We try to keep the library maintained as close as possible to the original library.
Pull Request resolved: https://github.com/facebook/yoga/pull/970
Reviewed By: yungsters
Differential Revision: D40027569
Pulled By: yungsters
fbshipit-source-id: ca9a6aa481c7b46e96c5937fe3cc7b716e464e4d
Summary:
https://github.com/facebook/yoga/pull/1116 added a change to the test generator "gentests.rb" to support a newer version of chromedriver, along with a change to the enum generator (not touched in this diff) to produce code consistent with the current tests, which seem to have been manually edited since last generation.
I had trouble running the test generator locally, because it relies on unversioned third-party dependencies, whose APIs change. Looking at source history, it seems like each time someone wants to run the script, they end up updating its syntax to match whatever versions they pull in.
This change adds a Gemfile and lock so that that the version of "watir" is locked, and so that we will also automatically pull in a consistent "chomedriver" version via the "webdrivers" gem. It includes the updates from the PR to be consistent with already output tests, and I have also updated the copyright header generation to no longer create lint warnings on newly generated tests (some of the previous ones were fixed manually it looks like).
The test generator would still produce bodies which would fail clang-format, and were manually edited (causing generation to emit new lint warnings), so I updated the generator to suppress clang-format in the body of the generated files.
Three tests, around the interaction of minimum dimensions and flexible children produce different results in Chrome now compared to when the tests were added, so running `gentests.rb` creates tests which break UTs. This doesn't seem like any sort of rounding, or device specific difference, so I have disabled these tests for now. While digging around, it does look like Chrome periodically will fix bugs in its own layout implementation which cause differences, like https://bugs.chromium.org/p/chromium/issues/detail?id=927066
Reviewed By: rozele, Andrey-Mishanin
Differential Revision: D39907416
fbshipit-source-id: f88714ff038b42f935901783452df25eabb6ebb1
Summary:
Our mission at Meta Open Source is to empower communities through open source, and we believe that it means building a welcoming and safe environment for all. As a part of this work, we are adding this banner in support for Ukraine during this crisis.
Pull Request resolved: https://github.com/facebook/yoga/pull/1134
Reviewed By: cortinico
Differential Revision: D34635677
Pulled By: dmitryvinn-fb
fbshipit-source-id: 492fb66b9d4cb218f422564dcef24089c2847603
Summary:
*Context: The Yoga OSS build has not been given a lot of attention over the past couple of years and is in serious disrepair. I'll try to get the release pipeline going again to publish to Maven Central as JCenter is shutting down. A bunch of intermediate commits may still have broken builds but will be inching closer to a working one.*
Adds some docs on how to use the release workflow.
Pull Request resolved: https://github.com/facebook/yoga/pull/1087
Reviewed By: priteshrnandgaonkar
Differential Revision: D28604686
Pulled By: passy
fbshipit-source-id: 44cac2cd0593a4f71d80df1ec5324c3c27fbe888
Summary:
As far as I can tell now. Would be nice if you had an actual changelog somewhere!
Pull Request resolved: https://github.com/facebook/yoga/pull/907
Differential Revision: D16701738
Pulled By: davidaurelio
fbshipit-source-id: cf32dc96eca5258979bcaa9947d6ed6b5496398d
Summary: Removes travis build as they were currently not in use and prevented website from being deployed.
Reviewed By: emilsjolander
Differential Revision: D7055369
fbshipit-source-id: f227b1da1fea748c526b9faeedef063f9eeff61f
Summary: Use internal linting rules instead of the custom once.
Differential Revision: D6284667
fbshipit-source-id: 65aae336f1d7f14dfefed7391b0f5b89b333495e
Summary:
For some reason this Universal.csproj wasn't pulled from rozele PR.. i added the missing files.
Added badges for build and nuget for more exposure.
Ignore a failing unit test on MacOS for a green build.
Closes https://github.com/facebook/yoga/pull/464
Reviewed By: emilsjolander
Differential Revision: D4670392
Pulled By: splhack
fbshipit-source-id: 9ea3150b92039cab87ce8696db983fdf373c5388
Summary: I accidentally used pngs for the bintray badges. This renders ugly sometimes. This corrects that.
Reviewed By: emilsjolander
Differential Revision: D4666641
fbshipit-source-id: df53f08a77be3067804d7671d673146f208a24fd
Summary: This adds bintray badges to the readme, and creates a readme for the android code.
Reviewed By: emilsjolander
Differential Revision: D4666314
fbshipit-source-id: a2549374f3e9c39c260160d1e32fb37801ff4208
Summary: Adds the Travis build badge for the android target to the README.md
Reviewed By: emilsjolander
Differential Revision: D4571693
fbshipit-source-id: a5110dac7d86989cc4a14b858c63d59332072869
Summary:
Hey there, congrats on the launch - we use React Native at Artsy, and I've been wondering about what Yoga + Jest Snapshots for RN looks like but haven't had the time to explore that yet.
With https://github.com/CocoaPods/cocoadocs.org/pull/501 I added the ability to customize the location of the README for the front-page of the CocoaPods site. That is being deployed as I speak, so it should be available the next time you decide to ship a version of Yoga.
I also fixed the capitalisation of CocoaPods, and removed a redundant CocoaPods badge on your initial README.
Closes https://github.com/facebook/yoga/pull/366
Reviewed By: emilsjolander
Differential Revision: D4488011
Pulled By: dshahidehpour
fbshipit-source-id: 6c0c4efc23a69e1fcb936214b159b49217218b49
Summary:
Benchmarks are not located in folder benchmark. So rename folder
and buck target from 'benchmarks' to 'benchmark'.
Closes https://github.com/facebook/yoga/pull/339
Reviewed By: gkassabli
Differential Revision: D4420355
Pulled By: emilsjolander
fbshipit-source-id: 7a1bc6ece7f4b64c7cac506357e265c1b4790a4f
Summary: Add notice in readme to prepare open source for large renaming diffs.
Reviewed By: splhack
Differential Revision: D4240761
fbshipit-source-id: 4c8070a06c3ac009b67eb7bef5de11ce3ab3e4d8
Summary:
When trying to integrate this into an Xcode project that already included CSSLayout.[c|h], we were getting a linker error.
Upon digging in, I found out that Xcode was becoming confused because the imports of the uikit library and the c library are both `#import <CSSLayout/CSSLayout.h>`. So, it needed a new name.
Reviewed By: emilsjolander
Differential Revision: D4162621
fbshipit-source-id: b5f7624eb29f1b9eaebbed5104ec9ea8a12ad2e5
Summary:
- Update README for gentest
- Fix gentest.rb for the right working dir
Reviewed By: emilsjolander
Differential Revision: D4065863
fbshipit-source-id: 5c6bd9d18779c05c1de24c06a83b148889facb6b
Summary: Update readme adding UIKit and fixing things that have changed
Differential Revision: D4015068
fbshipit-source-id: 213a60bea6f16ca01a4e613c8e3563f7c354ca8e
Summary:
This PR adds the C# version of the `CSSNode` API calls where it currently has only Java and C versions.
Closes https://github.com/facebook/css-layout/pull/225
Reviewed By: lucasr
Differential Revision: D3936431
Pulled By: emilsjolander
fbshipit-source-id: 689cb359c204c6c52e04e031c66615fb04c001af
Summary: Modify test generation script to be able to generate multiple test cases
Reviewed By: lucasr
Differential Revision: D3714577
fbshipit-source-id: d2bc2155712f946c5a24231a9532d2acc097524c
Summary: Java instructions were missing from the readme. Add a quick note about how to run tests in java.
Reviewed By: lucasr
Differential Revision: D3648981
fbshipit-source-id: d9009a60bb1bb0837722f914981ef4e31f0adb68
Summary: Update readme with info about building and github markdown syntax
Differential Revision: D3613284
fbshipit-source-id: 1f57009ccf02a48fe100f675ce08503e15cb6c22
The primary goals of this change are:
- Better conformance to the W3C flexbox standard (https://www.w3.org/TR/css-flexbox-1/)
and a clear articulation of the areas where it deviates from the spec.
- Support for flex-shrink.
- Conformance with layout effects of "overflow: hidden".
Specifically, here are the limitations of this implementation as compared to the W3C
flexbox standard (this is also documented in Layout.js):
- Display property is always assumed to be 'flex' except for Text nodes, which
are assumed to be 'inline-flex'.
- The 'zIndex' property (or any form of z ordering) is not supported. Nodes are
stacked in document order.
- The 'order' property is not supported. The order of flex items is always defined
by document order.
- The 'visibility' property is always assumed to be 'visible'. Values of 'collapse'
and 'hidden' are not supported.
- The 'wrap' property supports only 'nowrap' (which is the default) or 'wrap'. The
rarely-used 'wrap-reverse' is not supported.
- Rather than allowing arbitrary combinations of flexGrow, flexShrink and
flexBasis, this algorithm supports only the three most common combinations:
- flex: 0 is equiavlent to flex: 0 0 auto
- flex: n (where n is a positive value) is equivalent to flex: n 0 0
- flex: -1 (or any negative value) is equivalent to flex: 0 1 auto
- Margins cannot be specified as 'auto'. They must be specified in terms of pixel
values, and the default value is 0.
- The 'baseline' value is not supported for alignItems and alignSelf properties.
- Values of width, maxWidth, minWidth, height, maxHeight and minHeight must be
specified as pixel values, not as percentages.
- There is no support for calculation of dimensions based on intrinsic aspect ratios
(e.g. images).
- There is no support for forced breaks.
- It does not support vertical inline directions (top-to-bottom or bottom-to-top text).
And here is how the implementation deviates from the standard (this is also documented in
Layout.js):
- Section 4.5 of the spec indicates that all flex items have a default minimum
main size. For text blocks, for example, this is the width of the widest word.
Calculating the minimum width is expensive, so we forego it and assume a default
minimum main size of 0.
- Min/Max sizes in the main axis are not honored when resolving flexible lengths.
- The spec indicates that the default value for 'flexDirection' is 'row', but
the algorithm below assumes a default of 'column'.
also, on line 134, I could be wrong, but be wary of this sentence: "No C implementation of this function is provided in provided..." Perhaps this is a mistake.
thanks for all the awesome code!
