Summary:
This PR updates `typescript-eslint/eslint-plugin` and `typescript-eslint/parser` to `v7` and `eslint-plugin-jest` to `v27`, removing any dependencies on `typescript-eslint` `v6`, allowing projects using `react-native/eslint-config` to safely update to `typescript-eslint` `v7` without having to worry about duplicate major versions installed
## Changelog:
- [General] [Changed]: Updated `eslint-plugin-jest` to `v27`
- [General] [Changed]: Updated `typescript-eslint` monorepo to `v7`
Pull Request resolved: https://github.com/facebook/react-native/pull/43406
Test Plan: `yarn run lint` executed locally successfully
Reviewed By: robhogan
Differential Revision: D54749676
Pulled By: tdn120
fbshipit-source-id: f6fae92fc95333e28b36a3d2bd8470c8869d38bc
# Conflicts:
# package.json
# packages/eslint-config-react-native/package.json
# yarn.lock
Co-authored-by: Lluís <lluis@skrit.es>
Summary:
Now that RN is providing TS type information, many of those .d.ts files depend on types from react. In modern packagemanagers (Ex: pnpm) types/react will not be available to RN since it does not declare it as a dependency.
I also noticed that the types for react-native-popup-menu-android appear to be pointing to the wrong location.
Add types/react as a peerDependency on the packages that have .d.ts files that import from React.
Add types/react to peerDependencyMeta with optional:true to prevent users not using TS from requiring types/react.
[GENERAL] [ADDED] Added types/react as an optional peerDependency
Pull Request resolved: https://github.com/facebook/react-native/pull/43509
Reviewed By: cortinico
Differential Revision: D55225940
Pulled By: NickGerleman
fbshipit-source-id: 4cbab071928cb925baec45f55461559acc9a54e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41842
Changelog: [Internal]
- bumps `react-devtools-*` packages to 5.0.0 across xplat
- added support for highlighting multiple host components, when hovering over component, which is represented by multiple host fibers.
See test plan, this can be reproduced with a named component, which renders multiple host components inside a React Fragment:
```
<>
<View />
<View />
<View />
</>
```
Reviewed By: gsathya
Differential Revision: D51888628
fbshipit-source-id: 2bd2d9fa50c24f478aa9406ee6bb42a47168bf13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42019
Removes the following deprecated properties from React Native:
- `Image.propTypes`
- `Text.propTypes`
- `TextInput.propTypes`
- `ColorPropType`
- `EdgeInsetsPropType`
- `PointPropType`
- `ViewPropTypes`
The deprecation history for these prop types is not super obvious, so here is a summary:
- `react@15.5` extracted `prop-types` into a separate package to reflect that not everybody uses them.
- `react-native@0.68` added a deprecation warning to built-in prop types. (https://github.com/facebook/react-native/commit/3f629049ba9773793978cf9093c7a71af15e3e8d)
- `react-native@0.69` removed built-in prop types. (https://github.com/facebook/react-native/commit/3e229f27bc9c7556876ff776abf70147289d544b)
- `react-native@0.71` restored built-in prop types, along with bug fixes to isolate deprecated usage. (https://github.com/facebook/react-native/commit/b966d297245a4c1e2c744cfe571396cfa7e5ffd3)
We believe that by the next public release, enough time will have passed for the community to be able to upgrade without patching React Native or otherwise working around the removal of these deprecated prop types.
**If anyone has trouble identifying the source of a deleted prop types usage, please file an issue so we can help track it down with you.**
Changelog:
[General][Removed] - Removed deprecated prop types
Reviewed By: lunaleaps, NickGerleman
Differential Revision: D52337762
fbshipit-source-id: 9731f7e1dec29f3df535ab75cc50bed001fdfa0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41341
* Extends `dev-middleware`'s test utilities to enable testing against an HTTPS server with a self-signed cert.
* Runs the CDP transport integration tests (D51002261) using both HTTP and HTTPS.
* Adds a test to explicitly cover the `ws=...` / `wss=...` variation in `devtoolsFrontendUrl` first introduced in D49158227.
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D51006835
fbshipit-source-id: df3db8cd865898248cd0d8f307f75949a7f313fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41343
Changelog: [Internal]
Adds basic tests for two-way communication between a debugger (frontend) and a target (backend) using CDP over `inspector-proxy`.
Reviewed By: blakef
Differential Revision: D51002261
fbshipit-source-id: 44e571f89437c26e76ef6e6192b2bf6244665cf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39036
Changelog: [General][Changed] Use `hermes-parser` instead of `flow-parser` to parse Flow Codegen specs.
`hermes-parser` is a WASM build of the Hermes parser (plus supporting code), maintained by the Flow and Hermes teams. It is the recommended way of parsing Flow code in Node and its benefits (compared to `flow-parser`) include better performance and improved type safety.
Here we update `react-native/codegen` to use `hermes-parser` instead of `flow-parser`. Both parsers produce ASTs that conform to the ESTree spec so this is mostly a drop-in replacement.
In future work we should be able to use the improved AST types available in `hermes-estree` to improve type safety within `react-native/codegen` itself.
Reviewed By: huntie
Differential Revision: D48384078
fbshipit-source-id: 310ad150ec62671ba395b0e2f6415ccae97ac04d
Summary:
Though not currently in use in the RN code, when `react-native-windows` tried to integrate changes up to 7/28/23 (see PR https://github.com/microsoft/react-native-windows/pull/11970) there happened to be a `??=` operator in the `virtualized-lists` package (see [diff here](https://github.com/facebook/react-native/compare/ccc50ddd2...c168a4f88#diff-abeff2daf5909e54a23562e43569de1d5b8db1d7170119eed485b618cdf04ec7R322)). (The offending line was removed in a later commit).
The default RNW engine is still Chakra and it couldn't handle the syntax. It looks like the `babel/plugin-proposal-nullish-coalescing-operator` plugin only handles `??`, so to handle `??=` I've added `babel/plugin-proposal-logical-assignment-operators`, which also happens to handle the logical assignment operators `||=` and `&&=`.
Closes https://github.com/facebook/react-native/issues/31704
## Changelog:
[GENERAL] [FIXED] - Add detection of logical assignment operators to `react-native-babel-preset`
Pull Request resolved: https://github.com/facebook/react-native/pull/39186
Test Plan: We started using these plugins in RNW's babel config to resolve the issue in our integrate PR.
Reviewed By: motiz88
Differential Revision: D50936554
Pulled By: rozele
fbshipit-source-id: 0a924b6085524d8c9551a158b91195b1f7448c19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41219
Bump to the latest Metro release. This includes minor breaking changes to Metro subpackages that should *not* be visible to RN users.
Metro release notes: https://github.com/facebook/metro/releases/tag/v0.80.0
## Moving to unpinned versioning
Metro is a multi-package project, and not pinning to an exact version means multiple versions of `metro*` packages may appear in an RN project.
This isn't unusual in the NPM ecosystem and *shouldn't* be a problem, but historically has caused issues (eg https://github.com/facebook/react-native/issues/34714, https://github.com/facebook/metro/issues/1017). The root cause of all of these issues, as far as we know, was fixed in https://github.com/facebook/metro/commit/6d46078e74ae9a43aa90bed46dbd6610e2696cd0, a bug where Node hierarchical resolution was effectively sidestepped via a relative worker path, resulting in a mismatch between transformer and host process.
In addition, the fact that `react-refresh`, `metro-react-native-babel-transformer` and `metro-react-native-babel-preset` are now fully moved into the `react-native/` scope and versioned with React Native means there are no circular dependencies between React Native and Metro, explicit or implicit, and we're much more clearly decoupled.
So, we're moving to caret versioning to allow React Native users to pick up Metro fixes and features without requiring React Native releases and user upgrades.
Changelog:
[General][Changed] - Update Metro to ^v0.80.0, stop pinning to an exact version
Reviewed By: GijsWeterings
Differential Revision: D50731999
fbshipit-source-id: 57b07bf73c0b31f392c4d36376ca48b48a8bd598
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41067
Bump `hermes-parser` packages to the latest released version.
Changelog: https://github.com/facebook/hermes/blob/main/tools/hermes-parser/js/CHANGELOG.md
Notable changes:
- Added parsing support for `as` expressions as well as `renders*` and renders?`.
- Updated internal prettier version to `3.0.3`.
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D50395762
fbshipit-source-id: 8a9131ea1b0683e79c7bc74b4df9deafac7450f9
Szymon Rybczak
Alex HuntandLluís
Andrew Coates
Nicola Corti
Alex Taylor (alta)
Pieter De Baets
Alex Hunt
Pieter Vanderwerff
Moti Zilberman
Ruslan Lesiutin
Panos Vekris
Tim Yung
Michał Pierzchała
Sam Zhou
Ji An Yang
George Zahariev
Jon Thysell (JAUNTY)
Rob Hogan