[pull] main from facebook:main #107
Open
+17,075
−9,800
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Full list of changes: * DevTools: refactor NativeStyleEditor, don't use custom cache implementation ([hoxyq](https://github.com/hoxyq) in [#32298](#32298)) * fix[react-devtools-fusebox]: add extension globals to build ([hoxyq](https://github.com/hoxyq) in [#32297](#32297)) * DevTools: fix host component filter option title ([hoxyq](https://github.com/hoxyq) in [#32296](#32296)) * chore[DevTools]: make clipboardWrite optional for chromium ([hoxyq](https://github.com/hoxyq) in [#32262](#32262)) * DevTools: support useEffectEvent and forward-fix experimental prefix support ([hoxyq](https://github.com/hoxyq) in [#32106](#32106))
Same as what we did for `react-devtools-fusebox` in #32297.
…ion kinds (#32324) <!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. Before submitting a pull request, please make sure the following is done: 1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`. 2. Run `yarn` in the repository root. 3. If you've fixed a bug or added code that should be tested, add tests! 4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development. 5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`. 6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect". 7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`). 8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files. 9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`). 10. If you haven't already, complete the CLA. Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html --> ## Summary <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> Improve the error message, as the value is currently an object instead of a string, which results in it being converted to '[object Object]'. ## How did you test this change? Already tested locally. <!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. How exactly did you verify that your PR solves the issue you wanted to solve? If you leave this empty, your PR will very likely be closed. -->
Adds a new Timing logger event to the compiler which currently only records the walltime of running the compiler from the time the babel plugin's Program visitor enters to the time it exits. To enable, run the compiler with `ENABLE_REACT_COMPILER_TIMINGS=1 ...` or `export ENABLE_REACT_COMPILER_TIMINGS=1` to set it by default.
We don't need to wait for it to be labeled now that we have the shared maintainer check workflow. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32332). * #32333 * __->__ #32332
There's no real reason to have 2 jobs for sizebot. It's more of a historical artifact from before the GH migration. Merging them should require one less worker needing to be provisioned and some of the extra overhead --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32333). * __->__ #32333 * #32332
Our internal build infra relies on a 1:1 mapping between `main` and the 2 build branches. Directly committing changes to those branches breaks that infra. Adds a simple workflow to leave a comment and decline the PR.
…ition (#32342) This Hook is not available in RSC environments. This is already the case in stable but not in experimental for some reason. Probably an oversight.
Alternative to #32334
…es (#32349) Summary: Unblock internal sync. Test Plan: Reviewers: Subscribers: Tasks: Tags:
…tools (#30767) ## Summary This PR attempts to make running the React DevTools a little friendlier in projects that are not completely React. At the moment, running the DevTools with `npx react-devtools` will default to the port to use the `PORT` env variable otherwise it'll fall back to `8097`. `PORT` is a common env variable, so we can get into this strange situation where the a Rails server (eg Puma) is using `PORT`, and then the React DevTools attempts to boot using the same `PORT`. This PR introduces a dedicated env variable, `REACT_DEVTOOLS_PORT` to assist in this scenario. ## How did you test this change? I'm using fish shell, so I did the following, please let me know if there's a better way: ```sh cd packages/react-devtools set -x PORT 1000 set -x REACT_DEVTOOLS_PORT 2000 node bin.js ``` We can see in the UI that it's listening on `2000`. Without this PR, it'd listen on `1000`: 
Small refactor to the `resource` type to narrow it to an arbitrary object or void/null instead of the top type. This makes the overload on useEffect simpler since the return type of create is no longer widened to the top type when we merge their definitions. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32203). * #32206 * #32205 * #32204 * __->__ #32203
Rename the flag in preparation for the overload. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32204). * #32206 * #32205 * __->__ #32204
Merges the useResourceEffect API into useEffect while keeping the underlying implementation the same. useResourceEffect will be removed in the next diff. To fork between behavior we rely on a `typeof` check for the updater or destroy function in addition to the CRUD feature flag. This does now have to be checked every time (instead of inlined statically like before due to them being different hooks) which will incur some non-zero amount (possibly negligble) of overhead for every effect. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32205). * #32206 * __->__ #32205
Removes useResourceEffect. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32206). * __->__ #32206 * #32205
## Summary Fixes #32354. Re-creation of #15197: adds a dev-only warning if `create == null` to the three `use*Effect` functions: * `useEffect` * `useInsertionEffect` * `useLayoutEffect` Updates the warning to match the same text given in the `react/exhaustive-deps` lint rule. ## How did you test this change? I applied the changes manually within `node_modules/` on a local clone of https://github.com/JoshuaKGoldberg/repros/tree/react-use-effect-no-arguments. Please pardon me for opening a PR addressing a not-accepted issue. I was excited to get back to #15194 -> #15197 now that I have time. 🙂 --------- Co-authored-by: lauren <[email protected]>
## Summary In React Native, public instances and internal host nodes are not represented by the same object (ReactNativeElement & shadow nodes vs. just DOM elements), and the only one that's required for rendering is the shadow node. Public instances are generally only necessary when accessed via refs or events, and that usually happens for a small amount of components in the tree. This implements an optimization to create the public instance on demand, instead of eagerly creating it when creating the host node. We expect this to improve performance by reducing the logic we do per node and the number of object allocations. ## How did you test this change? Manually synced the changes to React Native and run Fantom tests and benchmarks, with the flag enabled and disabled. All tests pass in both cases, and benchmarks show a slight but consistent performance improvement.
Just a simple upgrade
…s` (#32372) <!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. Before submitting a pull request, please make sure the following is done: 1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`. 2. Run `yarn` in the repository root. 3. If you've fixed a bug or added code that should be tested, add tests! 4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development. 5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`. 6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect". 7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`). 8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files. 9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`). 10. If you haven't already, complete the CLA. Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html --> ## Summary <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> When using React Devtools, calling `console.log('%s', null)` in userland can cause it to throw an error: ``` TypeError: Cannot read properties of null (reading 'toString') ``` ## How did you test this change? Added a unit test. <!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. How exactly did you verify that your PR solves the issue you wanted to solve? If you leave this empty, your PR will very likely be closed. --> See 47ng/nuqs#808.
For Hookstate Proxies of class instances, `data.constructor.name`
returns `Proxy({})`, so use
`Object.getPrototypeOf(data).constructor.name` instead, which works
correctly from my testing.
<!--
Thanks for submitting a pull request!
We appreciate you spending the time to work on these changes. Please
provide enough information so that others can review your pull request.
The three fields below are mandatory.
Before submitting a pull request, please make sure the following is
done:
1. Fork [the repository](https://github.com/facebook/react) and create
your branch from `main`.
2. Run `yarn` in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch
TestName` is helpful in development.
5. Run `yarn test --prod` to test in the production environment. It
supports the same options as `yarn test`.
6. If you need a debugger, run `yarn test --debug --watch TestName`,
open `chrome://inspect`, and press "Inspect".
7. Format your code with
[prettier](https://github.com/prettier/prettier) (`yarn prettier`).
8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only
check changed files.
9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`).
10. If you haven't already, complete the CLA.
Learn more about contributing:
https://reactjs.org/docs/how-to-contribute.html
-->
## Summary
React DevTools immediately bricks itself if you inspect any component
that has a prop that is a Hookstate that wraps a class instance ...
because these are proxies where `data.constructor.name` returns some
un-cloneable object, but `Object.getPrototypeOf(data)` doesn't return
`Object` (it returns the prototype of the class inside).
## How did you test this change?
This part of the code has no associated tests at all.
Technically,
`packages/react-devtools-shared/src/__tests__/legacy/inspectElement-test.js`
exists, but I tried `yarn test` and these tests aren't even executed
anymore. I can't figure it out, so whatever.
If you run this code:
```js
class Class {}
const instance = new Class();
const instanceProxy = new Proxy(instance, {
get(target, key, receiver) {
if (key === 'constructor') {
return { name: new Proxy({}, {}) };
}
return Reflect.get(target, key, receiver);
},
});
```
then `instanceProxy.constructor.name` returns some proxy that cannot be
cloned, but `Object.getPrototypeOf(instanceProxy).constructor.name`
returns the correct value.
This PR fixes the devtools to use
`Object.getPrototypeOf(instanceProxy).constructor.name`.
I modified my local copy of devtools to use this method and it fixed the
bricking that I experienced.
Related #29954
…32353) Co-authored-by: Younes Henni <[email protected]>
Pending internal decision to ship in Canary. Still off for FB builds. Docs: reactjs/react.dev#7427
This Hook will be used to drive a View Transition based on a gesture. ```js const [value, startGesture] = useSwipeTransition(prev, current, next); ``` The `enableSwipeTransition` flag will depend on `enableViewTransition` flag but we may decide to ship them independently. This PR doesn't do anything interesting yet. There will be a lot more PRs to build out the actual functionality. This is just wiring up the plumbing for the new Hook. This first PR is mainly concerned with how the whole starts (and stops). The core API is the `startGesture` function (although there will be other conveniences added in the future). You can call this to start a gesture with a source provider. You can call this multiple times in one event to batch multiple Hooks listening to the same provider. However, each render can only handle one source provider at a time and so it does one render per scheduled gesture provider. This uses a separate `GestureLane` to drive gesture renders by marking the Hook as having an update on that lane. Then schedule a render. These renders should be blocking and in the same microtask as the `startGesture` to ensure it can block the paint. So it's similar to sync. It may not be possible to finish it synchronously e.g. if something suspends. If so, it just tries again later when it can like any other render. This can also happen because it also may not be possible to drive more than one gesture at a time like if we're limited to one View Transition per document. So right now you can only run one gesture at a time in practice. These renders never commit. This means that we can't clear the `GestureLane` the normal way. Instead, we have to clear only the root's `pendingLanes` if we don't have any new renders scheduled. Then wait until something else updates the Fiber after all gestures on it have stopped before it really clears.
…ed by Flow tooling syntax (#32382) ## Summary The `flow-api-translator` from the `hermes` repo does not support flow type spreads. It is currently not able to digest the ReactNativeTypes file as it contains unsupported syntax. The simplest solution is to change the type of the `TouchedViewDataAtPoint` to equivalent, yet supported by the Flow tooling. In this case the intersection can be used as the `TouchedViewDataAtPoint` and `InspectorData` have no common property. ## How did you test this change? Run yarn flow native
…2411) Since the compiler plugin is going to be merged into the hooks plugin, and ultimately decomposed into several more rules, it would be good to start creating a more traditional folder structure for the plugin. This change just moves the rules into a `rules` folder. Co-authored-by: lauren <[email protected]>
…onfig (#32457) This change swaps which config `recommended` is aliasing. In 5.2.0, the new flat config was introduced as `recommended-latest`, while `recommended` still pointed at the legacy rc-based config, with a note that in the next major version `recommended` would be updated to point at `recommend-latest`. This change makes that swap, and make the default `recommended` experience the flat config. To continue using the legacy rc recommended config, please make the following change in your config ```diff - extends: ['plugin:react-hooks/recommended'] + extends: ['plugin:react-hooks/recommended-legacy'] ``` This change also deprecates `recommended-latest` in favor of `recommended`. `recommended-latest` will be removed in a future major version. The README has been updated to reflect the new usage, and to put the flat config sections before the legacy config sections. I also took the opportunity to change the v9 fixture to use a typescript config, serving as a demonstration for usage as well as a way to validate the types are correct. BREAKING CHANGE --------- Co-authored-by: lauren <[email protected]>
Randomly noticed this when I looked at a recent [DevTools regression test run](https://github.com/facebook/react/actions/runs/13578385011). I don't recall why we added `continue-on-error` previously, but I believe it was to keep all jobs in the matrix running even if one were to fail, in order to fully identify any failures from code changes like build or test failures. There is now a `fail-fast` option which does this. [`continue-on-error`](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error) now means: > Prevents a workflow run from failing when a job fails. Set to true to allow a workflow run to pass when this job fails. so it's not correct to use it.
I end up rebuilding for testing the view-transition fixture a lot. It doesn't need everything that flight needs so this just adds a short hand that's a little faster to rebuild. --------- Co-authored-by: Hendrik Liebau <[email protected]>
We added support for `onScrollEnd` in #26789 but it only works in Chrome and Firefox. Safari still doesn't support `scrollend` and there's no indication that they will anytime soon so this polyfills it. While I don't particularly love our synthetic event system this tries to stay within the realm of how our other polyfills work. This implements all `onScrollEnd` events as a plugin. The basic principle is to first feature detect the `onscrollend` DOM property to see if there's native support and otherwise just use the native event. Then we listen to `scroll` events and set a timeout. If we don't get any more scroll events before the timeout we fire `onScrollEnd`. Basically debouncing it. If we're currently pressing down on touch or a mouse then we wait until it is lifted such as if you're scrolling with a finger or using the scrollbars on desktop but isn't currently moving. If we do get any native events even though we're in polyfilling mode, we use that as an indication to fire the `onScrollEnd` early. Part of the motivation is that this becomes extra useful pair for #32422. We also probably need these events to coincide with other gesture related internals so you're better off using our polyfill so they're synced.
numRequiredArgs has to be more than 0 and the pass depends on that --
Summary: Correctly supports React.useEffect when React is imported as `import * as React from 'react'` (as well as other namespaces as specified in the config).
…sions (#32498) This change adds more details about prior versions of the plugin's config, to help people as they migrate from legacy to flat configs across multiple versions of this plugin. At some point in the 6.0 or 7.0 cycle, it would probably make sense to re-consolidate this into a single version. Closes #32494
Will roll this out in www
…en (#32500) This is really the essence mechanism of the `useSwipeTransition` feature. We don't want to immediately switch to the destination state when starting a gesture. The effects remain mounted on the current state. We want the current state to be "live". This is important to for example allow a video to keeping playing while starting a swipe (think TikTok/Reels) and not stop until you've committed the action. The only thing that can be live is the "new" state. Therefore we treat the destination as the "old" state and perform a reverse animation from there. Ideally we could apply the old state to the DOM tree, take a snapshot and then revert it back in the mutation of `startViewTransition`. Unfortunately, the way `startViewTransition` was designed it always paints one frame of the "old" state which would lead this to cause a flicker. To work around this, we need to create a clone of any View Transition boundary that might be mutated and then render that offscreen. That way we can render the "current" state on screen and the "destination" state offscreen for the screenshots. Being mutated can be either due to React doing a DOM mutation or if a child boundary resizes that causes the parent to relayout. We don't have to do this for insertions or deletions since they only appear on one side. The worst case scenario is that we have to clone the whole root. That's what this first PR implements. We clone the container and if it's not absolutely positioned, we position it on top of the current one. If the container is `document` or `<html>` we instead clone the `<body>` tag since it's the only one we can insert a duplicate of. If the container is deep in the tree we clone just that even though technically we should probably clone the whole document in that case. We just keep the impact smaller. Ideally though we'd never hit this case. In fact, if we clone the document we issue a warning (always for now) since you probably should optimize this. In the future I intend to add optimizations when affected View Transition boundaries are absolutely positioned since they cannot possibly relayout the parent. This would be the ideal way to use this feature most efficiently but it still works without it. Since we render the "old" state outside the viewport, we need to then adjust the animation to put it back into the viewport. This is the trickiest part to get right while still preserving any customization of the View Transitions done using CSS. This current approach reapplies all the animations with adjusted keyframes. In the case of an "exit" the pseudo-element itself is positioned outside the viewport but since we can't programmatically update the style of the pseudo-element itself we instead adjust all the keyframes to put it back into the viewport. If there is no animation on the group we add one. In the case of an "update" the pseudo-element is positioned on the new state which is already inside the viewport. However, the auto-generated animation of the group has a starting keyframe that starts outside the viewport. In this case we need to adjust that keyframe. In the future I might explore a technique that inserts stylesheets instead of mutating the animations. It might be simpler. But whatever hacks work to maximize the compatibility is best.
Setting the animation's currentTime causes a quirk where the transition can end up off by a bit and the end state can be slightly off the end time. However, I realized that we don't have to because if we just set the direction in the `animate()` call directly the Safari bug goes away.
I don't think this is in use anymore
This is used to register Server References that exist in the current
environment but also exists in the server it might call into. Such as a
remote server.
If the value comes from the remote server in the first place then this
is called automatically to ensure that you can pass a reference back to
where it came from - even if the `serverModuleMap` option is used. This
was already the case when `serverModuleMap` wasn't passed. This is how
you can pass server references back to the server. However, when we
added `serverModuleMap` that pass was skipped because we were getting
real functions instead of proxies.
For functions that wasn't yet passed from the remote server to the
current server, we can register them eagerly just like we do for
`import('/server').registerServerReference()`. You can now also do this
with `import('/client').registerServerReference()`. We could make them
shared so you only have to do this once but it might not be possible to
pass to the remote server and the remote server might not even be the
same RSC renderer. Therefore I split them. It's up to the compiler
whether it should do that or not. It has to know that any function you
might call might be able to receive it. This is currently global to a
specific RSC renderer.
) <!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. Before submitting a pull request, please make sure the following is done: 1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`. 2. Run `yarn` in the repository root. 3. If you've fixed a bug or added code that should be tested, add tests! 4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development. 5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`. 6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect". 7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`). 8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files. 9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`). 10. If you haven't already, complete the CLA. Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html --> ## Summary <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> Adds changelog entries for the last two minor releases of `eslint-plugin-react-hooks`. Fixes #31717. I chose to not include #31208 (8382581) and #32115 (fd2d279) in the changelog as they only changed internals that do not affect consumers of the plugin, and it doesn't seem like the changelog previously included such changes. Changes are sorted by importance (rather than by commit date), with the most important changes first. ## How did you test this change? <!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. How exactly did you verify that your PR solves the issue you wanted to solve? If you leave this empty, your PR will very likely be closed. --> Docs only, nothing to test.
…th passChildrenWhenCloningPersistedNodes (#32528) <!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. Before submitting a pull request, please make sure the following is done: 1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`. 2. Run `yarn` in the repository root. 3. If you've fixed a bug or added code that should be tested, add tests! 4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development. 5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`. 6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect". 7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`). 8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files. 9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`). 10. If you haven't already, complete the CLA. Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html --> ## Summary <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> This PR fixes asserts when `passChildrenWhenCloningPersistedNodes` is enabled for React Native and OffscreenComponent child rendering unhides host components. Discussions around possible fixes for the asserts seen in React Native suggested changing the way we handle hiding/unhiding host components by updating the fiber state with the hidden host component instead of submitting a hidden clone Fabric and keeping the original as the current fiber. Implementing this fix would require holding onto the original styling of the hidden host component. The reconciler updates the styling by adding `display: none` to hide the contents. If the original host component was already hidden, the renderer would lose that information and remove the styling when showing the contents again. To reduce the changes required to make `passChildrenWhenCloningPersistedNodes` work, this PR falls back to the original cloning method when OffscreenComponents are part of the children needed to be added back. This effectively resolve the asserts triggered by the feature in RN and improves overall performance. ## How did you test this change? <!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. How exactly did you verify that your PR solves the issue you wanted to solve? If you leave this empty, your PR will very likely be closed. --> This fix was tested by enabling `passChildrenWhenCloningPersistedNodes` in an app built with React Native that had a repro for triggering the asserts. The asserts do not occur anymore when using the changes in this PR. --------- Co-authored-by: Nick <[email protected]>
Currently in the `compiler` workspace, we invoke esbuild directly to build most packages (with the exception of `snap`). This has been mostly fine, but does not allow us to do things like generate type declaration files. I would like #32416 to be able to consume the merged eslint-plugin-react-compiler from source rather than via npm, and one of the things that has come up from my exploration in that stack using the compiler from source is that babel-plugin-react-compiler is missing type declarations. This is primarily because React's build process uses rollup + rollup-plugin-typescript, which runs tsc. So the merged plugin needs to typecheck properly in order to build. An alternative might be to migrate to something like babel with rollup instead to simply strip types rather than typecheck before building. The minor downside of that approach is that we would need to manually maintain a d.ts file for eslint-plugin-react-hooks. For now I would like to see if this PR helps us make progress rather than go for the slightly worse alternative. [`tsup`](https://github.com/egoist/tsup) is esbuild based so build performance is comparable. It is slower when generating d.ts files, but it's still much faster than rollup which we used prior to esbuild. For now, I have turned off `dts` by default, and it is only passed when publishing on npm. If you want to also generate d.ts files you can run `yarn build --dts`. ``` # BEFORE: build all compiler packages (esbuild) $ time yarn build ✨ Done in 15.61s. yarn build 13.82s user 1.54s system 96% cpu 15.842 total # --- # AFTER: build all compiler packages (tsup) $ time yarn build ✨ Done in 12.39s. yarn build 12.58s user 1.68s system 106% cpu 13.350 total # --- # AFTER: build all compiler packages and type declarations (tsup) $ time yarn build --dts ✨ Done in 30.69s. yarn build 43.57s user 3.20s system 150% cpu 31.061 total ``` I still need to test if this unblocks #32416 but this stack can be landed independently though as we could probably just release type declarations on npm. No one should be using the compiler directly, but if they really wanted to, lack of type declarations would not stop them (cf React secret internals). Note that I still kept esbuild as we still use it directly for forgive. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32550). * #32551 * __->__ #32550
Fixes an incorrect condition for running tests in the compiler workspace. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32551). * __->__ #32551 * #32550
Use variant to begin rolling this out internally.
…et too (#32545) Otherwise these can survive into the next View Transition and cause havoc to that transition. This was appearing as a flash in Safari in the fixture when going from A->B. This triggers a View Transition and at the same time the scroll position updates in an effect. That fires a scroll event which starts a gesture. This shouldn't really happen and the SwipeRecognizer should ideally ignore those but it's good to surface edge cases. That gesture is blocked on the View Transition finishing and then immediately after it starts a gesture View Transition. That gesture then picked up the former Animation from the previous transition which caused issues. This PR fixes that flash.
Enabling feature detection of early DOM features in a framework is reckless. I'm not judging other frameworks (but also a little bit). Because if you do something like `if (moveBefore) moveBefore(a, b) else insertBefore(a, b)` like we do and then the implementation has to change there are still too many websites out there that it becomes impossible to change it. It would break the web. It would instead have to change to a different name. That's what happened with `contains` -> `includes`. Counter to popular belief it didn't have anything to do with patching prototypes. Therefore, ideally frameworks shouldn't start rely on it until there's two implementations so that there's time for feedback. That's why we didn't immediately enable this even in experimental. However, at this point there's probably enough feature detection and it has shipped long enough in Chrome that it's unlikely to be able to change at this point. We can enable it now. For now just in `@experimental` to see if we can flush out issues with it before bringing it to stable.
This fixes a critical issue with moveBefore. I was told that the disconnected -> connected case was going to be relaxed and not be an error but apparently that is not the case. This means that we can't use this for initial insertions. Only moves. Unfortunately React's internals doesn't distinguish these cases. This adds a hack that checks each nodes but this is pretty bad for performance. We should only call this in one or the other case. Given that we still need feature detection. Both of which means that these calls are no longer inlined and this extra code. I wonder if it's even worth it given that you can't even rely on it working anyway since not all browsers have it. Kind of don't want to ship this until all browsers have it. Even then we'd ideally refactor React to use separate code paths for initial insertion vs moves. Which leads to some unfortunate code duplication.
Accidentally copypasted the wrong esbuild config.
We customize the messages only in DEV to keep it small in prod. We skip some messages that are not really errors but more like information.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )