Summary:
This is a followup to D29514800.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D29647688
fbshipit-source-id: d6b7be96f4e0ec6ae97c11685be7e44a558116f2
Summary:
Changelog: [Internal] Upgrade glob-parent to 5.1.2 for vulnerability detection
Ran
```
yarn upgrade glob-parent@5.1.2
```
which then updated the package.json to add `glob-parent` as a direct dependency which I deleted.
then I ran
```
npx yarn-deduplicate yarn.lock; yarn
./scripts/update-oss-yarn-lockfile.sh // Not sure the purpose of this or the ordering
~/fbsource/xplat/third-party/yarn/tests/yarn-validate -d xplat/js/public
```
Reviewed By: GijsWeterings
Differential Revision: D29018576
fbshipit-source-id: b1e4f49a5f9c75ace290ed4f87eefeefdf80e58e
Summary:
This fixes how ES modules are handled in Jest tests in the react-native codebase.
They caused some problems before because `import` statements weren't inlined as `require` calls were, so there were some errors in tests when migrating from CommonJS to ESM.
This changes the transform that Jest uses to inline import statements the same way, so we can migrate everything without issues in tests.
Changelog: [Internal]
Reviewed By: kacieb
Differential Revision: D28899692
fbshipit-source-id: 027690f57ca3b5613c261a1089c0635af76662b2
Summary:
Bumped react-native-community/cli to v6 to update metro to 0.66 to fix fast-refresh issues
Also updated the manual test e2e script for easier testing. (using npm install would create a package-lock.json and conflict with yarn.lock)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[GENERAL] [UPDATE] - updated react-native-community/cli to v6 (hence updating metro to 0.66)
Pull Request resolved: https://github.com/facebook/react-native/pull/31597
Test Plan: I've tested fast-refresh works with / without hermes
Reviewed By: TheSavior
Differential Revision: D28852660
Pulled By: yungsters
fbshipit-source-id: af338e4dd1d52c62949d71f42773963d89bca9db
Summary:
API of Jest transformers is changing in Jest 27. The new version of `jest/create-cache-key-function` handles both current versions of the API and the upcoming 27 API.
Ref: https://github.com/facebook/jest/pull/10834
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Changed] - Use version of `jest/create-cache-key-function` compatible with upcoming Jest v27 release
Pull Request resolved: https://github.com/facebook/react-native/pull/30637
Test Plan: I've tested locally that it works with both a `jest@latest` and `jest@next` release.
Reviewed By: yungsters
Differential Revision: D28807361
Pulled By: hramos
fbshipit-source-id: 9d9ccb4d7f91b30bcbf3d28202bb74ce7499a91b
Summary:
Upgrade jsc-android to latest stable version. Hopefully this should finally fix https://github.com/facebook/react-native/issues/25494.
Before Hermes totally replaced JSC, it should be worth to have this and make JSC stable
## Changelog
[Android] [Changed] - Upgrade jsc-android to 250230.2.1
Pull Request resolved: https://github.com/facebook/react-native/pull/31304
Test Plan: Launch app with new jsc-android and see everything works fine.
Reviewed By: TheSavior
Differential Revision: D28630503
Pulled By: yungsters
fbshipit-source-id: 84510f91c81d4aaefe265d5492677ad6ff10e0fe
Summary:
Bump the cli version as it caused an issue when running the e2e tests for the 0.65 release
It will fix an incorrect template path being generated and fail the test
## Changelog
Bumped react native cli ? Already in the changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/31548
Test Plan: This is just a yarn.lock update targeting the cli
Reviewed By: fkgozali
Differential Revision: D28513554
Pulled By: Huxpro
fbshipit-source-id: 2957cb9e0d994894c3ef10260ee6167f857bdeef
Summary:
React DevTools has gotten pretty outdated in React Native. Let's fix that!
Last time I tried this it caused a lot of churn for tools like Flipper, so I approached this in two steps ([detailed in this post](https://fb.workplace.com/groups/rnsyncsquad/permalink/808063140086959/)).
First was a short term plan (as implemented in [PR 21344](https://github.com/facebook/react/pull/21344)) to:
1. Branch and make a patch release of DevTools 4.10 that adds a protocol check to the frontend (to detect any newer backends).
2. Upgrade Flipper (and recommend upgrade for the OSS React Native Debugger as well) to this new frontend.
3. Wait for the updated frontend to roll out.
The short term plan is now done, at least for the internal build of Flipper, and both GitHub PRs to update Flipper and React Native Debugger have been merged.
So this diff moves forward with the longer term plan (implemented in [PR 21331](https://github.com/facebook/react/pull/21331)):
1. Add an explicit version to the protocol used by the DevTools "backend" and "frontend" components to talk to each other.
2. Check this protocol during initialization to ensure it matches.
3. Show upgrade/downgrade instructions if there's a mismatch (or if the check times out without a response– indicating an older backend).
4. Release this as 4.13.
---
Changelog:
[General][Changed] - Upgrade `react-devtools-core` from ~4.6.0 to ^4.13.0
Reviewed By: yungsters
Differential Revision: D28103394
fbshipit-source-id: 21114294144bde9aede63cb3ba98a240082299bd
Summary:
Updates the Metro packages used in RN to v0.66.0, excluding the Metro server, which isn't a direct dependency.
Changelog:
[Internal]
Metro changelog:
https://github.com/facebook/metro/releases/tag/v0.66.0
Reviewed By: motiz88
Differential Revision: D27879399
fbshipit-source-id: e4014772d1fed2c93b32993fa2519f4e179a25a5
Summary:
Reverts D27764688 (https://github.com/facebook/react-native/commit/5a2693d78f1a886f0aa5b7f86830d3ddb54a57e9) due to a bug with "Invalid hook call." being erroneously reported. We will upgrade again after that bug is resolved.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D27813660
fbshipit-source-id: 84a12f19cf1bb7e8aebef0da3ff6f7022c391d3e
Summary:
After releasing https://github.com/facebook/metro/releases/tag/v0.65.1, I'm bumping the version here too.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D26450287
fbshipit-source-id: 1a6732ebd52e32e0e45ccd2cefffe762b8dcd824
Summary:
Currently, installing `react-native-community/eslint-config` with projects using eslint v7 causes the following warning
```
warning "react-native-community/eslint-config > eslint-plugin-react-native@3.8.1" has incorrect peer dependency "eslint@^3.17.0 || ^4 || ^5 || ^6".
```
This PR updates the eslint-plugin-react-native module to suppress the warning
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Changed] - update eslint-plugin-react-native for community eslint-config
Pull Request resolved: https://github.com/facebook/react-native/pull/30350
Test Plan: eslint working without error with projects using eslint v7
Reviewed By: GijsWeterings
Differential Revision: D25480912
Pulled By: nadiia
fbshipit-source-id: 2a956070e5bb75168d68501f9ec9486a34011349
Summary:
Upgrading CLI to latest. This diff is intended to be cherry-picked to 0.64.
cc grabbou kelset alloy
## Changelog
[Internal] [Changed] - Bump CLI to ^5.0.1-alpha.0
Pull Request resolved: https://github.com/facebook/react-native/pull/30420
Test Plan: None
Reviewed By: MichaReiser
Differential Revision: D25063261
Pulled By: cpojer
fbshipit-source-id: e1788fd40db2b00daaf888e7b2afaf708ade5451
Summary:
Monthly Babel update. As usual, I wait until there are multiple point releases because the Babel team tends to always break a lot of things in the first ~3 patch releases.
Release Notes: https://github.com/babel/babel/releases from 7.12.0 -> 7.12.6 inclusive. From a check of each change, nothing immediately jumps out as something that would impact us.
Changelog: [Internal]
Reviewed By: MichaReiser
Differential Revision: D24723845
fbshipit-source-id: 7db8daa119a4e34cd1fd4f61e7a635fcaf4e4a91
Summary:
## Context
We currently run ESLint using `flow-node`. This is a very recent change that was introduced in these two diffs:
- Switch VSCode ESLint plugin using flow-node: D24454702.
- Switch all ESLint scripts to use flow-node: D24379783 (https://github.com/facebook/react-native/commit/ad5802cf916c1cbe3e142385a29810a0d7205c6c).
## Problem
Because `react-native/eslint-plugin-codegen` (written in vanilla JavaScript) requires two files from `react-native-codegen` (written with Flow typings), we force all requires executed while initializing ESLint to compile out Flow types. Issues:
- In the grand scheme of things, this is such a tiny and isolated problem. It shouldn't be the reason why we switch over to using flow node. That's a larger decision that should be discussed outside of this diff.
- On VSCode cold start, in D24454702, I measured that using flow-node adds approximately 320ms to JavaScript file lint time. So, this is just slow.
## Solution
- Switch ESLint back to using regular node:
- Revert the changes to VSCode's ESLint plugin: D24454702
- Revert the changes to the internal ESLint scripts: D24379783 (https://github.com/facebook/react-native/commit/ad5802cf916c1cbe3e142385a29810a0d7205c6c).
- Inside the ESLint plugin, register a temporary require hook to remove Flow types from the NativeModule spec parser, before we require it. We de-register this hook after the requires finish.
## Implementation Notes:
- The `with-babel-register/` is a fork of `babel/register`, except I simplified the implementation based on the assumption that we're using it literally to only compile `react-native-codegen`.
- `with-babel-register/` uses a disk cache, so we only call transformSync when a the input file (1) hasn't been transformed before, or (2) the cache entry was created before the file was last modified.
- I ported over the source-map logic, so that when the NativeModule spec parser throws non-parsing errors, we get the correct stack trace. **Note:** I'm not sure if the source maps will work if there's a babel/register earlier during initialization. However, I don't think this will pose an actual problem, since we don't use a babel/register hook earlier. So, I think we should punt on this investigation.
## Alternative: Why aren't we using babel/register?
Every time you call babel/register, it replaces the last registered hook. We don't want the ESLint plugin to be changing any existing require hooks that people have set up. Abandoned diff with babel/register: D24519349.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D24551549
fbshipit-source-id: bbd7c5be44f74c0e9adbb20fe86e09802410b123