Summary:
**Motivation**
Minimum infra fix to enable subsequently landing https://github.com/react/react-native/pull/57940.
Referencing `ReactNativeFeatureFlags` on the existing `react-native/react-private-interface` boundary is blocked by a gap in the `build-types` pipeline and a type translation error, addressed here.
**Changes**
- `simpleResolve.js`: Explicitly support `react-native/react-private-interface` as a special case, fixing resolution.
- `ReactNativeFeatureFlagsBase.js`: Tweak the `OverridesFor` type here to fix TypeScript translation compatibility, where the unconstrained `T` type param is now narrowed.
**Impact**
No change to the API snapshot (the `ReactNativeFeatureFlags` import is ultimately tree-shaken!), and no effect on generated types until https://github.com/react/react-native/issues/57940 lands.
Changelog: [Internal]
Pull Request resolved: https://github.com/react/react-native/pull/58075
Test Plan:
- `yarn build-types`
- Applied https://github.com/react/react-native/issues/57940 patch on top; both stayed green, no `types_generated/**/featureflags/**`
Reviewed By: GijsWeterings
Differential Revision: D117513265
Pulled By: cortinico
fbshipit-source-id: 348e8de3d622081fe0062ef939ce14c21af587a8
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57851
The flow-* packages have support for all latest syntax and is better maintained.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D115064040
fbshipit-source-id: 7265eb722910a460c76d0dbde0603cf962fe4e4e
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57752
## Rationale
Flow lib defs that declare global types (available anywhere, without an `import`) must be referenced in `.flowconfig` and can't be maintained incrementally. That's not too bad for very stable APIs and it's necessary for environment/runtime globals, but for 3P libraries it makes the lib defs much more difficult to maintain for little benefit (we have to import the runtime APIs anyway). Secondarily, it's a problem for generating TypeScript types, as TS doesn't declare any 3P library globally.
Babel is one of few cases where a library declares Flow globals - every one has an importable equivalent.
## This diff
Replaces usages of Babel global types across xplat/js with their `babel/types` equivalents
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D113574665
fbshipit-source-id: be668d968345a60e76a3515d19d8eaa002d53274
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57628
NOTE: Patches over a `flow-api-translator` bug, which I'll fix upstream later. We need to pick this to `0.87-stable` to resolve user integration issues.
**Context**
TypeScript's `exactOptionalPropertyTypes` flag (strict mode) creates a distinction between `foo?: T` and `foo?: T | undefined`.
```js
// Flow's semantics
interface Props {
onRefresh?: () => void;
}
const a: Props = { onRefresh: undefined }; // ✅ ok
```
```ts
// TypeScript with exactOptionalPropertyTypes: true (i.e. strict mode)
interface Props {
onRefresh?: () => void;
}
const a: Props = { onRefresh: undefined }; // ❌ error
interface PropsFixed {
onRefresh?: (() => void) | undefined;
}
const b: PropsFixed = { onRefresh: undefined }; // ✅ ok
```
With this added strictness in TypeScript, our generated types via `flow-api-translator` could create downstream type incompatibility in apps.
**This diff**
Patches the above issue in React Native's Flow → TS `types_generated/` pipeline. We transform all instances to the wider `foo?: T | undefined` format, for maximum compatibility.
**Notes**
`foo?: T [| undefined]` **remains stripped** in the API snapshot (existing transform with the aim of a concise format). There is a net, nonfunctional snapshot diff around function members, which (as a positive result) are re-ordered.
Changelog:
[General][Fixed] - **Strict TypeScript API**: Optional property types are now widened to explicitly include `| undefined` for `exactOptionalPropertyTypes` compatibility
Reviewed By: cipolleschi
Differential Revision: D113030161
fbshipit-source-id: 3ab005edab6b80b18fbb9ae7125ba56e3bd94195
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57611
Directly follows D112733139 (Metro).
**Motivation**
- New Node builtins are *only* available under the prefix (e.g. `node:sqlite`), as this allows Node to introduce them without ecosystem-breaking changes, so this is the direction of travel and the only choice that'll allow consistency.
- Encouraging them and grouping them separately makes it easier to reason about a module's 3rd party dependencies.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D112803684
fbshipit-source-id: 40668d746a7151b3aa4800ff8af997902a18d198
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57490
See [**RFC0894: Removing deep imports from react-native**](https://github.com/react-native-community/discussions-and-proposals/pull/894)
This is the **big switch** to enable the Strict TypeScript API (generated types + single index entry point) by default in React Native.
**Opt-in → opt-out**
After this change, the main `react-native` package resolves its `"types"` entry points only to `types_generated/index.d.ts` — with no other subpaths available.
The new `"react-native-legacy-deep-imports"` condition maps to legacy `types/` and `Libraries/*.d.ts` sources.
**Impact limitation**: For this stage of rollout, the `"default"` condition continues to resolve to source files. Only TypeScript is affected.
**How to opt out**
Opposite of today's opt-in, which we will update in [the docs](https://reactnative.dev/docs/strict-typescript-api). Again, the only impact area today is **TypeScript**.
```json5
// tsconfig.json
{
"extends": "react-native/typescript-config",
"compilerOptions": {
...
"customConditions": ["react-native-legacy-deep-imports"]
}
}
```
**Other changes**
- Drop `react-native/typescript-config/strict` entry point, update README.
- Update `__typetests__`.
**Rollout plan**
**Target release: 0.87**. This and the contributing stack will be cherry picked for RC1.
- We've conducted testing against 100+ real Expo codebases, giving us the confidence that we've reduced breaking changes enough that the vast majority of RN codebases can migrate.
- The Strict API includes a number of **intentional breaking changes**, and docs have been kept up to date.
- We're shipping a `/migrate-to-strict-api` skill to migrate via agents, see https://github.com/react-native-community/skills/pull/3.
**What's improved since 0.80?**
Since the initial opt-in launch of the Strict API in 0.80, we've been making continuous improvements over the last year to get our generated types into a widely launchable state.
Most notably:
- 21+ new/updated root APIs and fixes due to community feedback ([discussion](https://github.com/react-native-community/discussions-and-proposals/discussions/893), [PRs](https://github.com/react/react-native/pulls?q=is%3Apr%20label%3A%22JS%20API%20stabilization%20(1.0)%22%20is%3Aclosed)).
- Upstream encapsulation blocker in TypeScript, fixed in 6.0 (https://github.com/react/react-native/issues/53565).
- Tailwind/Uniwind compatibility (`interface` types for props).
- `*Instance` ref type exports for all built-in components (https://github.com/react-native-community/discussions-and-proposals/pull/1003).
- Fixes to previously mistyped, high impact APIs, such as `Appearance`.
- New subpath entry points for `asset-registry`, `setup-env`, and others.
- Refinements to doc comments/type translation build.
**Rollback plan**
Revert this diff.
IMPORTANT: We'll adopt a policy of **super-eager rollback**, if there are any unsolvable issues during the RC phase.
Changelog:
[General][Breaking] - React Native's default JavaScript API is now the [Strict TypeScript API](https://reactnative.dev/docs/strict-typescript-api). Use `customConditions: ["react-native-legacy-deep-imports"]` to opt out.
Reviewed By: cortinico
Differential Revision: D110458670
fbshipit-source-id: 4b0e0b458a5f895f783d6d936e7b11ccff2df076
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57389
**Context**
Strict TypeScript API readiness: High quality inline docs should reach users via TypeScript in their IDEs.
**This diff**
Prior iterations of our Flow → TS translation stack dropped doc comments for default-exported values, and/or identifiers which change shape after type transformation (e.g. Flow `component` syntax), meaning many root APIs (`View`, `ScrollView`, `Pressable`, and others) showed no documentation on hover.
This diff extends the existing `reattachDocComments` transform to handle doc comment repositioning (suitable for the TS lang server) from a greater set of source positions:
- the exported declaration
- a `.displayName` assignment
- a HOC-wrapped inner component
- a renamed wrapper's public-named component
- a `declare const` / `declare export default typeof X` stub
**Impact**
(With the source code JSDoc improvements earlier in this stack.)
| Before (legacy types) | After (Strict API) |
| -- |
| {F1991869487} | {F1991869472} |
| ⚠️ No inline docs for many symbols | ✅ New, detailed inline docs reach the TS server 🎉 |
Changelog:
[General][Fixed] - Preserve doc comments on root API symbols in the generated TypeScript types
Reviewed By: rubennorte
Differential Revision: D109316361
fbshipit-source-id: 8a83455fcf317f355bd7c5a67712d322248d8b00
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57367
Places this one folder up, in a location that will be preserved when we later delete the manual `types/` dir. These tests already apply to both the `types/Libraries` dirs and the generated `types_generated/`.
Changelog: [Internal]
___
Differential Revision: D110055787
fbshipit-source-id: 5ff190d301628877c9bda57c92b1af1a2917f1ca
Summary:
Pull Request resolved: https://github.com/react/react-native/pull/57348
Follow-up to the `js1 build-cxx-api` rename. Move `build-geo-screenshot-tests`, `build-js-api`, and `build-twui-screenshot-tests` under the `build` group so they sit next to their siblings (`js1 build assets`, `js1 build turbomodule`, etc.) instead of being top-level hyphenated outliers.
Each old top-level command stays as a hidden alias that prints a deprecation notice and delegates to the new module, so existing muscle memory and any out-of-tree scripts keep working.
Also updates the two places that emit the old command names into user-visible output: the TWUI template comment headers, and the JS API snapshot failure message.
Changelog:
[Internal]
Reviewed By: zeyap
Differential Revision: D109844649
fbshipit-source-id: 00623fa8b4d724e16a2dc62d196182c32a9fed64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/57034
With D107165685, it should work this time.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D107111468
fbshipit-source-id: 326b2911088d7c87c3564a578125eeaab9d0b8cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/57028
Mark `ReactNativeElement` and `ReadOnlyNode` as non-user-constructible in the generated TypeScript definitions by emitting `protected constructor()`.
**Motivation**
- Correctness — like web DOM elements (`HTMLElement`, etc.), `ReactNativeElement` instances are created by the React Native runtime, not in user space. See also D107227212.
- Reduce public API surface (in particular, since this is also aliased to the `HostInstance` type).
**Changes**
- Adds a new `build-types protected-constructor` directive and corresponding `build-types` post-transform.
- Applies directive to `ReactNativeElement` and `ReadOnlyNode`.
- Also extracts shared `build-types` directive helpers into `transforms/typescript/utils/buildDirectives.js`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D107119545
fbshipit-source-id: 8320780db12475b00910745d4b8cee8c9f22d547
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56998
Reverts the recent Flow syntax codemods applied across `packages/`, `private/`, and `scripts/` in react-native-github. Specifically restores the previous form for:
- `+T` / `+Instance` style variance annotations on generic type parameters that had been converted to the newer `out T` / `in T` keyword form.
- `+field:` covariant object/interface properties that had been converted to the `readonly field:` modifier form.
- `+[K in keyof T]:` mapped-type covariance that had been converted to `readonly [K in keyof T]:`.
These are purely Flow type-annotation changes with no runtime behavior impact, restoring the form that the rest of the toolchain (in particular Fantom) already supports.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D106813102
fbshipit-source-id: 6bf915d530e130eba9c9d96a2b6c3dc8853594d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56809
#### Motivation
Adds (preserves) compatibility of Nativewind and Expo Web type augmentations with the Strict TypeScript API.
- These libraries rely on key React Native component types being defined as `interface`, not `type`, since TS module augmentation only supports `interface` declarations.
- Previously, our opt-in generated TypeScript types (Strict TypeScript API) emitted all props types as `type Foo = Readonly<...>` ), matching Flow source. However, this API change vs our manual types (which predominantly used `interface` on props) breaks library compatibility in these cases.
- This is very awkward to otherwise solve in user space — so opt for backwards compatibility in our new types.
#### Primer
TypeScript module augmentation lets a library extend an existing module's types without modifying the source.
e.g. In Nativewind ([source](https://www.nativewind.dev/docs/guides/third-party-components)):
```ts
declare module 'react-native' {
interface ScrollViewProps extends ViewProps, ScrollViewPropsIOS, ScrollViewPropsAndroid, Touchable {
contentContainerClassName?: string;
indicatorClassName?: string;
}
interface FlatListProps<ItemT> extends VirtualizedListProps<ItemT> {
columnWrapperClassName?: string;
}
interface ViewProps {
className?: string;
}
}
```
Expo's `react-native-web.d.ts` ([source](https://unpkg.com/expo@54.0.31/types/react-native-web.d.ts)) also follows the same pattern across several component props types.
#### Changes
Add new `build-types` transform, implementing an opt-in `/** build-types emit-as-interface */` annotation, converting eligible `type` aliases to `interface` declarations.
- Changing the Flow source files directly isn't viable — Flow doesn't support `interface extends Omit<>`, and several of these types use `Omit<>` in their composition. The post-transform operates on the TypeScript output where `interface extends Readonly<Omit<...>>` is valid.
The following emitted types are updated:
| Type | Augmented by | Source |
|---|---|---|
| `ViewProps` | `className?` | [Nativewind](https://www.nativewind.dev/docs/guides/third-party-components), [Expo](https://unpkg.com/expo@54.0.31/types/react-native-web.d.ts) |
| `ScrollViewProps` | `contentContainerClassName?`, `indicatorClassName?` | [Nativewind](https://www.nativewind.dev/docs/guides/third-party-components) |
| `ImagePropsBase` | `className?` | [Expo](https://unpkg.com/expo@54.0.31/types/react-native-web.d.ts) |
| `SwitchProps` | `className?` | [Expo](https://unpkg.com/expo@54.0.31/types/react-native-web.d.ts) |
| `TouchableWithoutFeedbackProps` | `className?` | [Expo](https://unpkg.com/expo@54.0.31/types/react-native-web.d.ts) |
| `InputAccessoryViewProps` | `className?` | [Expo](https://unpkg.com/expo@54.0.31/types/react-native-web.d.ts) |
`FlatListProps` is not included in this PR: its bare intersection (no `Readonly<>` wrapper) has a conflicting `fadingEdgeLength` property across constituent types that cannot be expressed as a single `extends` clause without hitting TS2320. This will be addressed in a follow-up.
`VirtualizedListWithoutRenderItemProps<T>` in `react-native/virtualized-lists` is separately owned and not changed here.
Changelog:
[General][Changed] - **Strict TypeScript API**: Select component props types are now `interface` declarations, enabling module augmentation by libraries like NativeWind and Expo (preserve compatibility)
Reviewed By: robhogan
Differential Revision: D104808984
fbshipit-source-id: 69c74fde1180a21c7241be53f010702710672638
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56824
Update the `simplifyTypes` transform (Flow → TS generation) to prune non-overlapping keys from `Omit<>` helpers in TypeScript `interface` unions.
This greatly reduces API snapshot churn/inflation in the next two diffs, which convert a number of `type` declarations (trivial unions) to `interface` (`Omit<>` required for correct union).
#### In detail
`flow-api-translator` emits `Omit<ParentType, keys>` to faithfully translate Flow's object spread override semantics to TypeScript.
```
// Flow
type Base = {x: string, y: number};
type Child = {...Base, x: boolean}; // Later properties in an object spread override earlier ones
// TypeScript
type Base = {x: string; y: number};
type Child = Omit<Base, "x" | "y"> & {x: boolean}; // Later properties in an object spread *merge*, rather than override. So we must use Omit<> for matched keys.
```
For `interface` type unions with overlapping keys, this can result in a number of unnecessary lines in the API snapshot, with little/no human readable value.
This diff extends existing `Omit<>` handling by `simplifyTypes` to recursively resolve all property keys reachable from a type, and prune keys that don't exist on the parent type.
```
// TypeScript
type Child = Omit<Base, "x"> & {x: boolean}; // Only "x" matched - strip `| "y"`
type ChildTwo = Base & {z: string}; // No property collision - strip entire `Omit<>`
```
- See changes to `ReactNativeApi.d.ts`, [P2325468482](https://www.internalfb.com/phabricator/paste/view/P2325468482?view=diff) for examples.
- **Decision point**: This diff opts to preserve correctness in TS — even though the snapshot isn't/isn't intended to be read directly/programatically, vs the conciseness tradeoff if we dropped all `Omit<>`s (human readable but ambiguous to the typechecker).
Changelog: [Internal] - JS API snapshot changes are a simplification refactor only
Reviewed By: robhogan
Differential Revision: D105150070
fbshipit-source-id: 43b0ef517164332a5cfaee7a5de5747749ac5e7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56772
Upgrades to TypeScript 6.0.3 and updates `typescript-eslint/*` for TS 6.0 compatibility across `react-native` and `metro`.
#### Motivation
TypeScript 6.0 (Mar 2026) will resolve https://github.com/facebook/react-native/issues/53565. Before updating in the React Native CLI template, align in RN and Metro source for consistency.
This is an internal change since:
- This upgrade only applies to TS analysis of these repos' source code.
- Edits to `react-native/typescript-config/tsconfig.json` (which *is* distributed) maintain backwards compatibility.
#### Changes
**react-native**
- Bump `typescript` from `^5.8.3` to `^6.0.3`
- Bump `typescript-eslint/*` from `^8.24.0` to `^8.59.2`
- Replace deprecated `moduleResolution: "node"` with `"node16"` and `target: "es5"` with `"es2015"` in codegen-typescript-test
- Add explicit `types: ["jest", "node"]` where needed (TS 6.0 defaults `types` to `[]`)
- Set `strict: false` in configs that only enable specific strict flags (TS 6.0 defaults `strict` to `true`)
- Update `ModuleResolutionKind.NodeJs` to `Node16` in build config
**metro**
- Bump `typescript` from `5.8.3` to `^6.0.3`
- Bump `typescript-eslint/*` from `^8.36.0` to `^8.59.2`
- No tsconfig changes needed (`tsconfig/node20` preset is already TS 6.0 compatible)
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D104658690
fbshipit-source-id: 9a2feeb257d5783431941a911b17065fcd0389a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56450
Changelog: [internal]
Update the `stripPrivateProperties` Flow transform to also remove
computed properties and methods from type definitions. These are
implementation details that should not be part of the public API.
Previously only underscore-prefixed identifiers were stripped. Now
`PropertyDefinition` and `MethodDefinition` nodes with
`node.computed === true` are also removed.
Reviewed By: huntie
Differential Revision: D100969511
fbshipit-source-id: 7eb1dfde99b56e9c460d83f6b12b7c31c3b04c92
Summary:
Two documentation errors in `scripts/js-api/README.md`:
1. **Wrong link text** (line 22): The link for the Flow-to-TypeScript converter reads `[flow-api-extractor](https://www.npmjs.com/package/flow-api-translator)` but the package name is `flow-api-translator`, not `flow-api-extractor`. The link URL was correct but the visible text was misleading.
2. **Wrong filename** (line 76): The Public API snapshot section refers to the file as `ReactNative.d.ts`, while the actual file committed to the repo is `ReactNativeApi.d.ts`. The correct name is already used earlier in the same document (line 16 and line 41).
Fixes https://github.com/facebook/react-native/issues/55667
Fixes https://github.com/facebook/react-native/issues/55668
## Changelog:
[General] [Fixed] - Fix incorrect package name and output filename in scripts/js-api/README.md
Pull Request resolved: https://github.com/facebook/react-native/pull/56362
Test Plan: Documentation-only change. Verified the link URL and the actual file name at `packages/react-native/ReactNativeApi.d.ts`.
Reviewed By: huntie
Differential Revision: D100761759
Pulled By: cortinico
fbshipit-source-id: 8a30ca1a5f35c9491c2ad4c94ae20da4621cb5a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55233
X-link: https://github.com/facebook/metro/pull/1640
Re-sync Flow Babel types with the latest version from npm to unbreak no-lockfile CI.
Metro only: Also `yarn-deduplicate` other deps
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D90986684
fbshipit-source-id: 332acd66c2ca1b3396388b383f1c940b19b899ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55136
Stacking another diff on top of hermes release. Let's see if there's still any CI failures.
` js1 flow-runner codemod flow/transformUtilityType --format-files=false --legacy-type='$Values' xplat/js`
drop-conflicts
Reviewed By: gkz
Differential Revision: D90549059
fbshipit-source-id: e07faa80b5ed0a675a2bc9bcc45d4084aaae9eda
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54901
At present, we're only using a rough heuristic for whether a code change to `ReactNativeApi.d.ts` is a breaking change. Introduce `POTENTIALLY_BREAKING` result level and update Danger warnings box.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D89287801
fbshipit-source-id: aced7911ecde37a1ad2c355d56ef0f0edde88fd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54822
Updates hash generation in `versionExportedApis.js` to track changes to `declare const` type declarations like `AccessibilityInfo_default`.
Previously, changes to APIs (e.g., `AccessibilityInfo`) would not always update their hashes in `ReactNativeApi.d.ts`, causing the breaking change detection to miss actual API changes.
Three issues prevented proper hash tracking:
1. **`VariableDeclaration` types weren't tracked** - `declare const X: {...}` was not in the list of tracked declaration types
2. **Duplicate declarations caused overwrites** - `declare type X = typeof X` would overwrite `declare const X: typeof X_default` in the declarations map, losing the dependency on `X_default`
3. **`typeof X` queries weren't extracting dependencies** - references via `typeof` weren't being added to the dependency graph
## Fix
- Add `t.isVariableDeclaration(node)` to tracked types with proper name extraction
- Prevent overwriting existing declarations (first declaration wins)
- Handle `TSTypeQuery` nodes to extract `typeof X` dependencies
### Note on Hash Changes
This PR causes many hashes to change, even for types that haven't been modified. This is expected because the hash computation now includes `declare const` dependencies that were previously ignored.
**Before:** `AccessibilityInfo` hash only included `declare type AccessibilityInfo = typeof AccessibilityInfo` (self-reference)
**After:** Hash now includes `declare const AccessibilityInfo: typeof AccessibilityInfo_default` + the full `AccessibilityInfo_default` type
## Changelog:
[GENERAL] [FIXED] - hash generation includes `declare const` types in API snapshot
Reviewed By: huntie
Differential Revision: D88653322
fbshipit-source-id: abdf9c5e11bf8ff9e6e2f17a743a2d5aa213ae1c
Summary:
This replaces `glob@^7.0.0` with `tinyglobby@^0.2.15`. `glob@7` has been deprecated for a while and some versions after had security notices released for them. The plan is to backport this PR to `0.81.x` and onwards.
> [!NOTE]
> This is a stopgap solution until `fs.glob` becomes generally available with the EOL of Node v20
Succeeds:
- https://github.com/facebook/react-native/issues/54669
- https://github.com/facebook/react-native/issues/48875
## Changelog:
[GENERAL] [SECURITY] - Replace `glob@^7.0.0` with `tinyglobby@^0.2.15`
Pull Request resolved: https://github.com/facebook/react-native/pull/54737
Test Plan:
- Ran all modified commands manually and `pod install in `rn-tester`
- NOTE: `ios-prebuild`-related scripts haven't been run manually yet
Reviewed By: robhogan
Differential Revision: D88069145
Pulled By: huntie
fbshipit-source-id: 0c455342a4c6d1d6605fd09fe47b418e5d751491
Summary:
In Flow 0.284, we will have a stricter version of `Array<T>.includes`. Instead of accepting `mixed`, we will only accept `T` to help catch logical errors. We did the same for `Array.indexOf` and `Array.lastIndexOf` as well.
This diff pre-suppresses newly discovered errors in part of the codebase.
Changelog: [Internal]
Reviewed By: marcoww6
Differential Revision: D82784398
fbshipit-source-id: 6cb11809844f964e0604d33b9f7a3989074cd1cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52768
Prettier v3 has an async API. This diff adds in await ahead of the upgrade to prepare for the API change.
Changelog: [Internal]
Reviewed By: pieterv
Differential Revision: D78752354
fbshipit-source-id: c0d27a6c863747b71852e72a22687d1fe1d9f76f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52473
Shared utils that were located in the root of `scripts/` are now colocated closer to their dependencies or moved to `scripts/shared/` — simplifying the root directory layout.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D77873875
fbshipit-source-id: e04dba41a1ef811d32793931033fdfa93afad0cd
Alex Hunt