Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51840
Bumps the minimum version of Node.js in React Native to the current active LTS release (22.x, upgraded from 18.x which is now out of support).
- CI configurations are reduced from `[22, 20, 18]` to `[24, 22]`.
{F1978909878}
See https://nodejs.org/en/about/previous-releases.
Changelog:
[General][Breaking] - Our new minimum Node version is Node.js 22
Reviewed By: yungsters, cortinico
Differential Revision: D76037015
fbshipit-source-id: b6e4b3ee279a9a93d716a13297420bba73f45250
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49658
This bumps the version of Node that we use to build React Native from 18 to 20.
We'll still be supporting building with 20, but we'll moving our toolchain to Node 20 becuase 18 is at EOL soon.
Changelog:
[General] [Changed] - Bump Node 18 -> 20 to build React Native in OSS
Reviewed By: javache, cipolleschi
Differential Revision: D70168003
fbshipit-source-id: b64ee583b2d2e72d25393119ae9e9029a74d5b13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48237
Noticed this when trying to diagnose what seemed like a stale caching issue. It effectively reverts D59917944.
D59917944 added logic to only do yarn caching on main, but it has some correctness issues:
1. We cache `node_modules` instead of the yarn cache, which may contain e.g. build artifacts, or other scratch/cache files written (such as anything that writes to `node_modules/.cache`). We really want to be caching the yarn cache, which has pristine packages before install, which I think it will also need to perform the real install anyways.
2. We key the cache on root `package.json`, which is missing a lot of information (both provided by the other `package.json` in the repo, but mostly, the lockfile resolution).
We only save cache when we're on `refs/heads/main` (so continuous builds against main), and supposedly, builds against base branch should be able to restore against those, but recent PR jobs I have seen, where `package.json` has not changed, all have `Cache not found for input keys: node-modules-068350889e87919c1c6c2c220c8d2d92db13f38820bf2efb315d1274b97bc367`
Because of the potential correctness issues, and that the strategy for limiting to main seemingly is not allowing cache to be used in PR, this diff goes back to previous solution, which may store more artifacts (but working cache should also reduce cost by making jobs run faster).
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D67140004
fbshipit-source-id: f74074a498af56b1837fa23cf80795f76935b762
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45544
## This diff now does 5 things:
1. removes the old way we used `actions/setup-node` to manage the cache itself.
2. it creates a new `update-node-modules-cache` workflow, which is the only job that will update the node modules cache
3. it create a `yarn-install-with-cache` action that should be used install of directly calling `yarn install --non-interactive`. This will load a cache against a hash of `package.json`.
4. updated the cache reaper to aggressively remove everything but the latest `npm-{{ hash('package.json') }}`.
5. removed a `cache-setup`, which couldn't be used (we're using artefacts now).
## Why are we doing this:
The various `node-cache-` keys for platforms and on various branches accounts for a very large proportion of the cache (10-20%).
We don't frequently change these dependencies, and even when we do running `yarn install` after loading the cache will resolve any issues.
Limiting the cache to `main` and aggressively pruning older cache entries will clean up a lot of "small win" caching.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59917944
fbshipit-source-id: 4be6f1959e8fde642a4f208f7d19aceba2c3262f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45542
As we do have several version numbers for external actions all across the codebase,
here I'm aligning all of them to just use the majors.
I'm doing it only for GitHub first party actions as we trust them,
so minor/patch changes can safely be pulled in without code changes.
Changelog:
[Internal] [Changed] - Align github/* action versions on major
Reviewed By: cipolleschi, blakef
Differential Revision: D59959978
fbshipit-source-id: bb07ce0dfd74d9502a2ac0ea90a2b32f55d6d655
