

In order to make use of the compiler in stable releases (eg React 19 RC, canary), we need to export the compiler runtime in the stable channel as well.


CLA Signed

Opened by a member of the React Core Team

React Core Team

Export __COMPILER_RUNTIME in stable

[ez] Update useMemoCache return type

ESLint plugin react hooks version: 4.6.0

## Steps To Reproduce

```tsx
const MyComponent = () => {
  const array = useMemo(() => ["banana", "apple"], []);

  const filteredArray = array.filter((element) => element !== "apple");

  useEffect(() => {
    console.log("If this is printed, array has changed");
  }, [array]);

  useEffect(() => {
    console.log("If this is printed, filteredArray has changed");
  }, [filteredArray]);

  const [counter, setCounter] = useState(0);

  return <button onClick={() => setCounter(counter + 1)}>Re-render</button>;
};
```

## Feature request
The exhaustive-deps rule already warns for functions declared in the scope of a component, which will be re-declared at each render and thus be a problem if put inside the dependency array of a `useEffect`, `useCallback` or `useMemo`. I recently had a problem when applying the `.filter()` method on a memoized array, since the new resulting array is a new one at each render.

I was wondering if it would be possible to warn for this kind of issues as well, the same way functions declared inside the component are currently warned.

I don't have an exhaustive list of such methods (that return a new object from a given one) that would be warned, other than `.filter()` and `.map()`, perhaps people in the comments can propose others?

## Where to do this
I have dived a little bit in the code of the package and found the `scanForConstructions` function ([here](https://github.com/facebook/react/blob/380f5d675d2269f090d15c3f92e10de66e12516c/packages/eslint-plugin-react-hooks/src/ExhaustiveDeps.js#L1584)) that seems to be the one that checks for the functions. If this is the way to do it, I could try to implement this other behaviour in this same function.


A potential issue that we haven't yet confirmed as a bug

Status: Unconfirmed

[Feature Request] Warn for arrays resulting of `.map()` or `.filter()` in hook dependencies

### Website or app

How do I use react-devtools in react-native projects on Android phones

### Repro steps

How do I use react-devtools in react-native projects on Android phones

### How often does this bug happen?

Every time

### DevTools package (automated)

How do I use react-devtools in react-native projects on Android phones

### DevTools version (automated)

How do I use react-devtools in react-native projects on Android phones

### Error message (automated)

How do I use react-devtools in react-native projects on Android phones

### Error call stack (automated)

```text
How do I use react-devtools in react-native projects on Android phones
```


### Error component stack (automated)

```text
How do I use react-devtools in react-native projects on Android phones
```


### GitHub query string (automated)

```text
How do I use react-devtools in react-native projects on Android phones
```


Type: Bug

Component: Developer Tools

How do I use react-devtools in react-native projects on Android phones

Stacked on #31528 et al.

It's useful to quickly see where new events are kicking off new rendering. This uses the new "warning" color (yellow) to do that. This is to help distinguish it from the purple (secondary color) which is used for the commit phase which is more of a follow up and it's often that you have several rerenders within one event which makes it hard to tell a part where it starts and event otherwise.

For the span marking between previous render within the same event and the next setState, I use secondary-light (light purple) since it's kind of still part of the same sequence at that point. It's usually a spawned render (e.g. setState in useEffect or microtask) but it can also be sequential flushSync.

I was bothered by that the event name is the only thing that's lower case so I prefixed it with `Event: ` like the JS traces are.

<img width="1499" alt="Screenshot 2024-11-13 at 7 15 45 PM" src="https://github.com/user-attachments/assets/0c81c810-6b5d-4fc7-9bc0-d15b53844ade">

It might be a little confusing why our track starts earlier than the JS one below in the "Main Thread" flamegraph which looks the same. That's because ours is the start of the event time which is when the click happens where as the Main Thread one is when the JS event loop gets around to processing the event.



Format event with "warning" yellow and prefix with "Event: "

React version: 18.3.1

## Steps To Reproduce

Open DevTools Network tab and check "disable cache" to see how much data is requested.

1. Render a long list of `<img>` tags with `loading="lazy"` (placed after the `src` attribute)
2. (only a few top images are loaded, you can see max few hundred kb downloaded)
3. Unrender the list
4. Render the list again
5. (all of them are requested, you can see many mb being downloaded)



Link to code example: https://codesandbox.io/p/sandbox/react-18-forked-2f9q8l?workspaceId=1b03e581-57eb-43f2-80b8-0d9e38ede5b5 (additional explanation below)



## The current behavior

Under certain circumstances, all the images are loaded when remounted with React, despite `loading="lazy"` being specified.

The example code above, provides two ways in which the images are removed from DOM and then added again: one using react state, and the other using simple native DOM methods. Turns out that only when React renders the list (and only when it's done for the second+ time), the lazy loading is broken. With DOM methods, you can remount the images many times and every time only few top images are loaded.

There's also a button to switch the position of `loading="lazy"` attribute to be before or after `src=`. It shows that order makes difference and issue occurs only when the `loading` attribute is placed after `src`.

There used to be a bug in Firefox that caused the lazy loading to not work when loading attribute is placed after src, but it is gone and was never a problem in Chrome. Yet, somehow, the way in which React adds the nodes to DOM, reproduces the bug even in Chrome.

I am personally experiencing it in Chrome version 131.0.6778.70 (64bit, windows).

## The expected behavior

No matter the order of attributes, the behavior should be as per the standard browser behavior. It shouldn't matter that it's React appending the nodes or which time it's doing it.

Bug: Images with `loading="lazy"` remounted with react are all loaded

When you schedule a microtask from render or effect and then call setState (or ping) from there, the "event" is the event that React scheduled (which will be a postMessage). The event time of this new render will be before the last render finished.

We usually clamp these but in this scenario the update doesn't happen while a render is happening. Causing overlapping events.

Before:

<img width="1229" alt="Screenshot 2024-11-12 at 11 01 30 PM" src="https://github.com/user-attachments/assets/9652cf3b-b358-453c-b295-1239cbb15952">

Therefore when we finalize a render we need to store the end of the last render so when we a new update comes in later with an event time earlier than that, we know to clamp it.

There's also a special case here where when we enter the `RootDidNotComplete` or `RootSuspendedWithDelay` case we neither leave the root as in progress nor commit it. Those needs to finalize too. Really this should be modeled as a suspended track that we haven't added yet. That's the gap between "Blocked" and "message" below.

After:

<img width="1471" alt="Screenshot 2024-11-13 at 12 31 34 AM" src="https://github.com/user-attachments/assets/b24f994e-9055-4b10-ad29-ad9b36302ffc">

I also fixed an issue where we may log the same event name multiple times if we're rendering more than once in the same event. In this case I just leave a blank trace between the last commit and the next update.

I also adding ignoring of the "message" event at all in these cases when the event is from React's scheduling itself.

Fix Overlapping "message" Bug in Performance Track

We don't log a phase like "Throttled" or "Suspended" for this case so it can leave a tiny gap otherwise.

This ensures it connects without a seam.

<img width="1059" alt="Screenshot 2024-11-12 at 9 34 17 PM" src="https://github.com/user-attachments/assets/7ed4a3c7-b508-4fc1-b956-44c4e31faa4d">


Use completedRenderEndTime as the start of the commit phase if it's an immediate commit

Fixes a bug.

We're supposed to not log "Waiting for Paint" if the passive effect phase was forced since we weren't really waiting until the paint. Instead we just log an empty string when we force it to still ensure continuity.

We should always log the passive phase. This check was in the wrong place.


Log passive commit phase when it wasn't delayed

Previously we were showing Components inside each lane track but that meant that as soon as you expanded a lane you couldn't see the other line so you couldn't get an overview over how well things were scheduled.

This instead moves all the Components into a single top-level track and renames the previous one to a "Scheduler" track group.

<img width="1352" alt="Screenshot 2024-11-12 at 8 26 05 PM" src="https://github.com/user-attachments/assets/590bc6d3-3540-4ee4-b474-5d733b8d8d8d">

That way you can get an overview over what React is working on first and then right below see which Component is being worked on.

Ideally the "Scheduler" track would be always expanded since each Track is always just a single row. Now you have to expand each lane to see the labels but then you're wasting a lot of vertical real estate. There's currently no option to create this with the Chrome performance.measure extensions.

<img width="1277" alt="Screenshot 2024-11-12 at 8 26 16 PM" src="https://github.com/user-attachments/assets/4fc39e35-10ec-4452-ad32-c1c2e6b5e1a8">


Separate Tracks for Components and Phases

## Summary

This fixes a typo in the error that gets reported when Float errors while hoisting a style tag that does not contain both `precedence` and `href`. There was a typo in _conflict_ and the last part of the sentence doesn't make sense. I assume it wasn't needed since the message already suggests moving the style tag to the head manually. 

(chore): copy fix in <style> precedence error


This PR introduces a new experimental hook `useResourceEffect`, which is something that we're doing some very early initial tests on.

This may likely not pan out and will be removed or modified if so. Please do not rely on it as it will break.


[crud] Basic implementation


We were previously filtering out `ref.current` dependencies in propagateScopeDependencies:checkValidDependency`. This is incorrect.

Instead, we now always take a dependency on ref values (the outer box) as they may be reactive. Pruning is done in pruneNonReactiveDependencies.

This PR includes a small patch to `collectReactiveIdentifier`. Prior to this, we conservatively assumed that pruned scopes always produced reactive declarations. This assumption fixed a bug with non-reactivity, but some of these declarations are `useRef` calls. Now we have special handling for this case
```js
// This often produces a pruned scope
React.useRef(1);
```
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/31521).
* #31200
* __->__ #31521

[compiler] Fix: ref.current now correctly reactive

## Summary



I am cross-posting an issue I made with Preact and Voby 
https://github.com/preactjs/preact/issues/4555
https://github.com/vobyjs/voby/issues/45

Type: Discussion

Align on HTML attribute/property casing (ie not camelCase)

### What kind of issue is this?

- [X] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [ ] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhAMygOzgFwJYSYAEAggBTBFhwwQA2dAChGEQL4CURwAOsUXEJgcRANoI6AGioIcAUToBdIgF4iAJQQBDXADooYBAGUcWnAjIcA3Hz5EiBhABktAT2jy0aBLjKXVAHzcRHb2RBK61LQMTghoImpR9EwsNvxs0uJSVDTJzGCKHLb8MLKwxAA8ACZ4AG5EpWgqwIbydGwBFQD0NbUBaWwgbEA

### Repro steps

Sometimes we need to "mutate" a html element, e.g. when dealing with scrolling.

But with this code we get an error:
> Mutating a value returned from 'useState()', which should not be mutated. Use the setter function to update instead

### How often does this bug happen?

Every time

### What version of React are you using?

18.3.1

### What version of React Compiler are you using?

19.0.0-beta-a7bf2bd-20241110

Component: Optimizing Compiler

[Compiler Bug]: Cannot alter scroll values on a element -  Mutating a value returned from 'useState'

## Summary

https://github.com/SimenB/react-19-compiler-runtime

Using `react-compiler-runtime` always loads the polyfill. Probably because `react` does not have the `__COMPILER_RUNTIME` export it's looking for.

React 19

[React 19]: `react-compiler-runtime` always polyfills, even in React 19

### What kind of issue is this?

- [ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [X] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

`npm install eslint-plugin-react-compiler@beta --save-dev`

### Repro steps

1. 
```sh
npm install eslint-plugin-react-compiler@beta --save-dev
```

Message: `npm warn deprecated @babel/plugin-proposal-private-methods@7.18.6: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-private-methods instead.`

### How often does this bug happen?

Every time

### What version of React are you using?

18.3.1

### What version of React Compiler are you using?

N/A

[Compiler Bug]: `eslint-plugin-react-compiler`: npm warn deprecated `@babel/plugin-proposal-private-methods`

## Summary
Related Previous Issues: https://github.com/facebook/react/issues/30041
Related Previous PR: https://github.com/facebook/react/pull/30365

There was already a PR raised, but I wrote a PR to be more specific and prevent type errors.

When passing an asynchronous function to a <form> action, if you pass that action again before receiving the response, the stateHook.next value will be null in the `ensureFormComponentIsStateful` function running inside the requestFormReset function, resulting in a type error. To prevent this problem, I modified the `ensureFormComponentIsStateful` function to maintain the current statefull state if the `stateHook.next` value is null. 

## Test Code
```javascript
function App() {
  const formAction = async () => {
    await new Promise((resolve) => setTimeout(resolve, 3000));
  };
  return (
    <form action={formAction}>
      <input type="text" name="name" />
      <input type="submit" />
    </form>
  );
}
export default App;
```

## Test Step
1. Enter any text in input text.
2. Submit.
3. Submit multiple times within 3 seconds (setTimeout time). 
(usually after 2-3 seconds, just before the response comes)

## How did you test this change?

- codesandbox: https://codesandbox.io/p/sandbox/react-19-form-reset-error-l79dq5
- React Version: 19.0.0-rc-5c56b873-20241107
- local test and `yarn test`.
![react19-form-action-error](https://github.com/user-attachments/assets/dca553b9-9d23-40b0-8a91-10e0d615c138)

If there is anything wrong, please tell me.

[React 19] When submitting a form action multiple times, requestFormReset throws the TypeError 'Cannot read null property (reading 'queue')'.

## Summary



## How did you test this change?

Delete concurrentRoot option from ReactFabric.render

## Summary



I deleted `mountWorkInProgressOffscreenFiber`.

The prop type of `createFiberFromOffscreen` is now specified as `OffscreenProps`, not any.

Therefore, I thought `mountWorkInProgressOffscreenFiber` was an unnecessary function.

<img width="591" alt="image" src="https://github.com/user-attachments/assets/455c9980-3037-4ead-b5f8-c5286d0b5e89">

<img width="539" alt="image" src="https://github.com/user-attachments/assets/135b73a9-997d-4850-a111-2e129c80de88">


## How did you test this change?

fix: remove mountWorkInProgressOffscreenFiber function

Certainly! Here's the updated version of the issue with the link to the ReactPress repository included:

---

**Title**: Inquiry About React 19 Support for ReactPress

**Body**:

Hello ReactPress Team,

I hope this message finds you well. I am currently evaluating [ReactPress](https://github.com/fecommunity/reactpress) for a project and have a question regarding its compatibility with future versions of React. Specifically, I would like to know if there are any plans or ongoing efforts to ensure that ReactPress supports React 19.

React 19 introduces several new features and improvements that could potentially benefit ReactPress. As such, I am keen to understand if the team is already working on integrating these changes or if there are any known issues that might prevent ReactPress from running smoothly on React 19.

Here are a few specific questions I have:

1. Is ReactPress currently compatible with React 19?
2. If not, are there any plans to update ReactPress to support React 19 in the future?
3. Are there any known issues or limitations that users should be aware of if they try to use ReactPress with React 19?

I appreciate your time and effort in maintaining this wonderful project. Thank you for any information you can provide regarding this matter.

Best regards,

fecommunity

[React 19]Inquiry About React 19 Support for ReactPress

### What kind of issue is this?

- [X] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [X] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhAgHgBwjALgAjggDswCBZATwGETcMCBeQmBAQ3tuPvVwApgAHWKCebALaYANggBKCAGbJ8wOLFbdlxKFKkBfYXoCUw4Rmx58AE0VsdBBVGJxcASxL4ACmw25akkgRuPiMVYXxCEjJ8DAlpOUV8ZigwBIU+AHIAOQgMkxFiCNZcWEK+cIj8AB4APgrK6qouHlwAOk8YCAA3VxsYfC62KSgERmBgWMkZeQU9PTrChsqq6gALVykrf2xiIIIAegWl6v2mugZ2zp6+o+XDiqMAbkNTYkdnNw81ja2IAN3gqEhIsiKQCMAYug4tNEnokvgUghmgw+GduAx8hVEQBRBQKBAuPghJI1MKLCKTeIzVpqGC+eEZACaCDAGQqegANPgANqUmEKAC6+QiFWKpWqVlcXXuxAMxBAeiAA

### Repro steps

1. Instantiate a Context
2. In Parent, Instantiate a ref
3. Wrap the child in the Context's Provider, and pass the ref as a value
4. Get the ref in the child, and mutate it in a useEffect

### How often does this bug happen?

Every time

### What version of React are you using?

18.3.1

### What version of React Compiler are you using?

19.0.0-beta-63b359f-20241101

[Compiler Bug]: "Mutating a value returned from 'useContext()', which should not be mutated" When the value is a Ref

### What kind of issue is this?

- [X] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [X] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhAgHgBwjALgAgBMEAzAQygBsCSoA7OXASwjvwAUyYE7cBhCAFtsdHrgAUASnzAAOm3xxWYAhjLDKCAEql8AXnxQw20uIDkAOQhnJ8+fnzdcsNuPsP8AHgB87j174ACyZKQgFhVjEZADpY4DUNExIAX2T8AHpfBX9PQiYAN3xWPkomOABrPWApPW85bP9FZQhNaMoIAHNzAAkyfIR8IJDCQ2MAURISBEYwfAAjBB5HegB+MwAafATMTR0SaLhYbl5bBodUjKyczPdJAG55ZLs6WgZmVkHg0PCRMXF49DqHZJZLSeoOIwICZTRjiKT6bwyPxbQGJPYHI5RAxmACaCDAZncyU2AG1trtSABdU7uJwuLx5fI3OhPOggZJAA

### Repro steps

1. Instantiate a ref in the parent
2. Mutate the current property in a useEffect in the child

### How often does this bug happen?

Every time

### What version of React are you using?

18.3.1

### What version of React Compiler are you using?

19.0.0-beta-63b359f-20241101

[Compiler Bug]: "InvalidReact: Mutating component props or hook arguments is not allowed" When Passing a MutableRef as a prop, then mutating it in child

## Summary


Issue: #31467

I noticed the status variable in the ReactPromise function of the ReactFlightClient file, is of type any. After carefully checking every other mention of this variable to make sure about it's type, I changed it into string to better suite the intented type and avoid risk of bugs.

![screen](https://github.com/user-attachments/assets/44dcfeeb-ae85-4f59-bed2-f6bf07e8796d)

## How did you test this change?

I run the following commands: 
- yarn
- yarn test

Status variable type

I noticed the status variable in the ReactPromise function of the ReactFlightClient file, is of type any.

If the status is always of type String, it would be a good idea to replace `any` with `string`. This helps provide stronger type checking, reduces the risk of bugs, and improves code readability.

[ReactFlightClient.js](https://github.com/facebook/react/blob/main/packages/react-client/src/ReactFlightClient.js)
line: 206

![function](https://github.com/user-attachments/assets/34d5db34-4d29-4f3b-810f-7518c964a99b)


Bug: Change status variable type

### Website or app

private

### Repro steps

profile re-renders click on individual re-renders. Clicked on the last re-render and it crashed instead of displaying info.

### How often does this bug happen?

Only once

### DevTools package (automated)

react-devtools-extensions

### DevTools version (automated)

6.0.0-d66fa02a30

### Error message (automated)

getCommitTree(): Invalid commit "7" for root "1". There are only "7" commits.

### Error call stack (automated)

```text
ve/<@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1159236
CommitFlamegraphAutoSizer@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1404914
renderWithHooks@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:52244
updateFunctionComponent@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:81718
beginWork@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:95937
performUnitOfWork@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:154622
workLoopSync@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:154498
renderRootSync@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:154249
performWorkOnRoot@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:149824
performSyncWorkOnRoot@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:164884
flushSyncWorkAcrossRoots_impl@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:163205
processRootScheduleInMicrotask@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:163662
1519/ensureRootIsScheduled/<@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:162805
```


### Error component stack (automated)

```text
CommitFlamegraphAutoSizer@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1404715
div@unknown:0:0
div@unknown:0:0
div@unknown:0:0
SettingsModalContextController@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1297733
wl<@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1536567
fa@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1315530
div@unknown:0:0
div@unknown:0:0
ThemeProvider@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1318230
portaledContent/<@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1318420
div@unknown:0:0
div@unknown:0:0
div@unknown:0:0
ThemeProvider@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1318230
TimelineContextController@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1395885
ProfilerContextController@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1387636
TreeContextController@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1209953
SettingsContextController@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1238133
ModalDialogContextController@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1375334
DevTools_DevTools@moz-extension://beb769c0-41a5-4f80-ba39-12fab791919f/build/main.js:1:1544294
```


### GitHub query string (automated)

```text
https://api.github.com/search/issues?q=getCommitTree(): Invalid commit  for root . There are only  commits. in:title is:issue is:open is:public label:"Component: Developer Tools" repo:facebook/react
```


[DevTools Bug] getCommitTree(): Invalid commit "7" for root "1". There are only "7" commits.

### What kind of issue is this?

- [X] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [ ] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhAejQAgMIBsCWcA1vgHYDmmALgBYKYK4IC2CpVmA7vrrpmXBgs2HWvTgFimONHYAdUhkwBDUgBNMAMwjxxEZgAcIpEZiEBaIeoQwFSgMoD6AN2W4oCAIwr1mV+4QAJhUhTCgwMkoAA3CEAFkWCCiufFpMOyxVBkMqAE9MNQQDNkLSOHzlGBhlXIAaajp8sBpoXA1SCA44GlVyBAA6DMwAdVSaHH0DHhsGUmUAIyY1ev8PYO7ehDBB0gUEAA8jGA5CzWUoXA5NKDKqfGNMONyAQQMDAAoASkxgBUxMJRgKgLJgqQQQMBgMwlGxgP7SYxAvxuDzeAC8YTA8US7y+mDRAD5HspaP1qup9F96gBtAC6nwA3Ap4UoOhwgSD6MpwZDodYYFDOFgZIZpjB0qR-kp5lAOPhBWNoF1JmKmZKAcKspwdEQQrINOFIhKpcLERxqasgrUAPq0-GYhD2YFUBC476E4mk8lqSnfADUmE8n0+8JkpCRluCGNiCWYEDd+KJcRJNDJqh9zDxAc8NPpapZwskJAoKV40MsMNs6rDSOpAiErHY9SxVAAkmUGyI7dGsU6Sa6AAyM5nqoRUWCSgA8anwzkwxjwhCIaOAeI9LfbgmE7He+ET-Ew2c+AF8CRIl8hgPXt1RjysUV5L5bPHfkQFAk+H4Fj5O0DPnASarHiAx5AA

### Repro steps

1. Write a `useMemo` function that uses Math.random() AND some other value or function, for example:
-  `const val = useMemo(() => Math.random() + 0, []);`
- `const val = useMemo(() => Math.floor(Math.random()), []);`
2. Cause the component to re-render
3. The resulting value will be re-computed on re-render

In associated repro link, clicking the component increments a counter which triggers re-render. Without compiler both memoized values are stable; with compiler, only the first is.

### How often does this bug happen?

Every time

### What version of React are you using?

18.3.1

### What version of React Compiler are you using?

19.0.0-beta-8a03594-20241020

[Compiler Bug]: useMemo does not provide stable results across renders for specific functions when compiler enabled

## Summary
`@rollup/plugin-typescript` emits a warning while building, hinting that `outputToFilesystem` defaults to true.

Although "noEmit" is set to `true` for the tsconfig, rollup writes a `dist/.tsbuildinfo`. That file is then also shipped inside the npm module and doesn't offer any benefit for library consumers. Setting this option to false results in the file not being written and thus omitted from the npm module.

## How did you test this change?
`dist/.tsbuildinfo` is not emitted any more.

[compiler] Disable emit of .tsbuildinfo

Hi! 
I just migrated to the new eslint flat config file and I am getting the following error when I want to omit the
 `react-hooks/exhaustived-deps` rule:
 
![image](https://github.com/user-attachments/assets/20930ec2-ecff-4ac5-8727-02c1607f1158)


React version: "^18.3.1"

## Steps To Reproduce
I created a reproduction environment starting from the `vite-react` template provided by stackblitz and convertit to webpack. 
❗When using vite, this error doesn't appear. 
If you remove the comment `// eslint-disable-line react-hooks/exhaustive-deps` and run `npm run lint` you will get in the terminal the warning provided by eslint to add a dependency to the useLayoutEffect array. 
When I have the comment, the `npm run lint` run wihtout warnings or errors.
https://stackblitz.com/edit/vitejs-vite-egb7ki?file=src%2FApp.jsx

## The current behavior
Definition for rule 'react-hooks/exhaustive-deps' was not found

## The expected behavior
To be able to omit 'react-hooks/exhaustive-deps' when I need to.

Thanks!

Bug: Definition for rule 'react-hooks/exhaustive-deps' was not found

# Summary

I'm working to get the main `react-native` package parsable by modern Flow tooling (both `flow-bundler`, `flow-api-translator`).

This diff trivially removes some redundant Flow comment syntax in `ReactNativeTypes.js`, which fixes parsing under these newer tools.

## How did you test this change?

Files were pasted into `react-native-github` under fbsource, where Flow validates ✅.
