Minor Jest upgrade #3
Closed
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
…26064) Need to add types to these two maps to unblock React Native sync.
The old token was revoked, this updates the token by reading from CI secrets instead, I'm not sure there's benefit in making it publicly visible.
## Summary resolves facebook#26051 After we upgrade to Manifest V3, the browser no longer allow us to run `eval` within the extension. It's not a problem for prod build, but for dev build, webpack has been using eval to inject the source map for devtool. This PR changes it to an alternative method.
This renames Module References to Client References, since they are in the server->client direction. I also changed the Proxies exposed from the `node-register` loader to provide better error messages. Ideally, some of this should be replicated in the ESM loader too but neither are the source of truth. We'll replicate this in the static form in the Next.js loaders. cc @huozhi @shuding - All references are now functions so that when you call them on the server, we can yield a better error message. - References that are themselves already referring to an export name are now proxies that error when you dot into them. - `use(...)` can now be used on a client reference to unwrap it server side and then pass a reference to the awaited value.
Revert facebook@353c30252. The commit breaks old React Native where `nativeFabricUIManager` is undefined. I need to add unit test for this to make sure it doesn't happen in the future and create a mechanism to deal with undefined `nativeFabricUIManager`. This is to unblock React sync to React Native.
…acebook#26016) ## Summary The flag was first added in facebook#16157 and was rolled out to employees in D17430095. facebook#25997 removed this flag because it wasn't dynamically set to a value in www. The www side was mistakenly removed in D41851685 due to deprecation of a TypedJSModule but we still want to keep this flag, so let's add it back in + add a GK on the www side to match the previous rollout. See D42574435 for the dynamic value change in www ## How did you test this change? ``` yarn test yarn test --prod ```
I fully enabled this flag internally now and unless I see complications, we should be able to clean this up in the code.
The old version of prettier we were using didn't support the Flow syntax to access properties in a type using `SomeType['prop']`. This updates `prettier` and `rollup-plugin-prettier` to the latest versions. I added the prettier config `arrowParens: "avoid"` to reduce the diff size as the default has changed in Prettier 2.0. The largest amount of changes comes from function expressions now having a space. This doesn't have an option to preserve the old behavior, so we have to update this.
## Summary Removing package jest-mock-scheduler introduced in PR facebook#14358, as it is no longer referenced in the main branch code. The following files previously referenced it: - packages/scheduler/src/__tests__/Scheduler-test.js - packages/scheduler/src/__tests__/SchedulerDOM-test.js - packages/shared/__tests__/ReactDOMFrameScheduling-test.js - scripts/jest/setupTests.js - scripts/rollup/bundles.js ## How did you test this change? ci green
## Summary This PR removes the unused dependency 'abort-controller' from the project. it helps to keep the project clean and maintainable. ## How did you test this change? ci green
This is just shifting around some encoding strategies for Flight in
preparation for more types.
```
S1:"react.suspense"
J2:["$", "$1", {children: "@3"}]
J3:"Hello"
```
```
1:"$Sreact.suspense"
2:["$", "$1", {children: "$L3"}]
3:"Hello"
```
This frees up the Webpack manifest to contain a `serverManifest` part too. @shuding
This lets you pass Promises from server components to client components and `use()` them there. We still don't support Promises as children on the client, so we need to support both. This will be a lot simpler when we remove the need to encode children as lazy since we don't need the lazy encoding anymore then. I noticed that this test failed because we don't synchronously resolve instrumented Promises if they're lazy. The second fix calls `.then()` early to ensure that this lazy initialization can happen eagerly. ~It felt silly to do this with an empty function or something, so I just did the attachment of ping listeners early here. It's also a little silly since they will ping the currently running render for no reason if it's synchronously available.~ EDIT: That didn't work because a ping might interrupt the current render. Probably need a bigger refactor. We could add another extension but we've already taken a lot of liberties with the Promise protocol. At least this is one that doesn't need extension of the protocol as much. Any sub-class of promises could do this.
This is because Webpack has a `typeof ... === 'object'` before its esm
compat test.
This is unfortunate because it means we can't have a nice error in CJS
when someone does this:
```
const fn = require('client-fn');
fn();
```
I also fixed some checks in the validator that read off the client ref.
It shouldn't do those checks against a client ref, since those now
throw.
`flow-remove-types` was also upgraded to the latest version.
If the publish-prereleases command fails to access CircleCI, it will now exit with a message instead of hanging indefinitely.
…k#26083)" (facebook#26111) Just kidding. We're not going to need any other fields afaik after all.
…#26117) The "dom" configuration is actually the node specific configuration. It just happened to be that this was the mainline variant before so it was implied but with so many variants, this is less obvious now. The "bun" configuration is specifically for "bun". There's no "native" renderer for "bun" yet.
The current caching of steps of `node_modules` doesn't work reliable as
is because it includes `arch` in the cache key. `arch` might be
different across workers in the same commit.
I couldn't find a way to optionally restore caches, so what this PR does
is:
- remove the setup step that ran before all other steps and essentially
just populates a circle CI cache key
- all other steps now do: restore yarn cache, `yarn install`, save yarn
cache (fast if already exists)
With this change the initial batch of jobs all race to populate the
cache, but any subsequent jobs should find the existing cache. The
expected downside would be slightly more worker CPU time with all the
parallel jobs, but wall time might be shorter (1 step less in the
critical path) and we should be more reliable as we no longer have the
failure with multiple archs.
## Alternative 1
Remove the `{arch}` from the cache key.
Downside: this might run into weird issues with native dependencies.
## Alternative 2
Somehow check if the cache was restored and only then run a yarn
install.
Downside: couldn't figure out if it's possible to only restore the yarn
cache if restoring the node_modules cache failed. Without that we'd
either always restore both the yarn and node_modules cache or do yarn
installs w/o cache which are prone to failure in the past.
## Summary This is to fix some edge cases I recently observed when developing and using the extension: - When you reload the page, there's a chance that a port (most likely the devtools one) is not properly unloaded. In this case, the React DevTools will stop working unless you create a new tab. - For unknown reasons, Chrome sometimes spins up two service worker processes. In this case, an error will be thrown "duplicate ID when registering content script" and sometimes interrupt the execution of the rest of service worker. This is an attempt to make the logic more robust - Automatically shutting down the double pipe if the message fails, and allowing the runtime to rebuild the double pipe. - Log the error message so Chrome believes we've handled it and will not interrupt the execution. This also seems to be helpful in fixing facebook#25806.
## Summary Prettier was bumped recently. So any branch not including that bump, might bring in outdated formatting (e.g. facebook#26068) ## How did you test this change? - [x] `yarn prettier-all`
…#26118) This updates the Flight fixture to support the new ESM loaders in newer versions of Node.js. It also uses native fetch since react-fetch is gone now. (This part requires Node 18 to run the fixture.) I also updated everything to use the `"use client"` convention instead of file name based convention. The biggest hack here is that the Webpack plugin now just writes every `.js` file in the manifest. This needs to be more scoped. In practice, this new convention effectively requires you to traverse the server graph first to find the actual used files. This is enough to at least run our own fixture though. I didn't update the "blocks" fixture. More details in each commit message.
We currently abuse the browser builds for Web streams derived environments. We already have a special build for Bun but we should also have one for [other "edge" runtimes](https://runtime-keys.proposal.wintercg.org/) so that we can maximally take advantage of the APIs that exist on each platform. In practice, we currently check for a global property called `AsyncLocalStorage` in the server browser builds which we shouldn't really do since browsers likely won't ever have it. Additionally, this should probably move to an import which we can't add to actual browser builds where that will be an invalid import. So it has to be a separate build. That's not done yet in this PR but Vercel will follow Cloudflare's lead here. The `deno` key still points to the browser build since there's no AsyncLocalStorage there but it could use this same or a custom build if support is added.
<!-- 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 debug-test --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 pull request emit the trace update events `drawTraceUpdates` with the trace frame information when the trace update drawer runs outside of web environment. This allows React Devtool running in mobile or other platforms have a chance to render such highlights and provide similar feature on web to provide re-render highlights. This is a feature needed for identifying unnecessary re-renders. ## 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. --> I tested this change with Flipper desktop app running against mobile app, and verified that the event with correct array of frames are passing through properly.
as reported in facebook#26128 `ReactDOM.render(..., document)` crashed when `enableHostSingletons` was on. This is because it had a different way of clearing the container than `createRoot(document)`. I updated the legacy implementation to share the clearing behavior of `creatRoot` which will preserve the singleton instances. I also removed the warning saying not to use `document.body` as a container
…bundle size (facebook#26122) <!-- 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 debug-test --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 This PR: - Replaces the existing usages of methods from the `semver` library in the React DevTools source with an inlined version based on https://www.npmjs.com/package/semver-compare. This appears to drop the unminified bundle sizes of 3 separate `react-devtools-extensions` build artifacts by about 50K:  ## How did you test this change? I was originally working on [a fork of React DevTools](replayio#2) for use with https://replay.io , specifically our integration of the React DevTools UI to show the React component tree while users are debugging a recorded application. As part of the dev work on that fork, I wanted to shrink the bundle size of the extension's generated JS build artifacts. I noted that the official NPM `semver` library was taking up a noticeable chunk of space in the bundles, and saw that it's only being used in a handful of places to do some very simple version string comparisons. I was able to replace the `semver` imports and usages with a simple alternate comparison function, and confirmed via hands-on checks and console logging that the checks behaved the same way. Given that, I wanted to upstream this particular change to help shrink the real extension's bundle sizes. I know that it's an extension, so bundle size isn't _as_ critical a concern as it would be for a pure library. But, smaller download sizes do benefit all users, and that also includes sites like CodeSandbox and Replay that are using the React DevTools as a library as well. I'm happy to tweak this PR if necessary. Thanks!
facebook#26127) ## Summary Prefer `getChildrenAsJSX` or `toMatchRenderedOutput` over `getChildren`. Use `dangerouslyGetChildren` if you really need to (e.g. for `toBe` assertions). Prefer `getPendingChildrenAsJSX` over `getPendingChildren`. Use `dangerouslyGetPendingChildren` if you really need to (e.g. for `toBe` assertions). `ReactNoop.getChildren` contains the fibers as non-enumerable properties. If you pass the children to `toEqual` and have a mismatch, Jest performance is very poor (to the point of causing out-of-memory crashes e.g. https://app.circleci.com/pipelines/github/facebook/react/38084/workflows/02ca0cbb-bab4-4c19-8d7d-ada814eeebb9/jobs/624297/parallel-runs/5?filterBy=ALL&invite=true#step-106-27). Mismatches can sometimes be intended e.g. on gated tests. Instead, I converted almost all of the `toEqual` assertions to `toMatchRenderedOutput` assertions or compare the JSX instead. For ReactNoopPersistent we still use `getChildren` since we have assertions on referential equality. `toMatchRenderedOutput` is more accurate in some instances anyway. I highlighted some of those more accurate assertions in review-comments. ## How did you test this change? - [x] `CIRCLE_NODE_TOTAL=20 CIRCLE_NODE_INDEX=5 yarn test -r=experimental --env=development --ci`: Can take up to 350s (and use up to 7GB of memory) on `main` but 11s on this branch - [x] No more slow `yarn test` parallel runs of `yarn_test` jobs (the steps in these runs should take <1min but sometimes they take 3min and end with OOM like https://app.circleci.com/pipelines/github/facebook/react/38084/workflows/02ca0cbb-bab4-4c19-8d7d-ada814eeebb9/jobs/624258/parallel-runs/5?filterBy=ALL: Looks good with a sample size of 1 https://app.circleci.com/pipelines/github/facebook/react/38110/workflows/745109a2-b86b-429f-8c01-9b23a245417a/jobs/624651
Co-authored-by: eps1lon <silbermann.sebastian@gmail.com>
## Summary - yarn.lock diff +-6249, **small pr** - use jest-environment-jsdom by default - uncaught error from jsdom is an error object instead of strings - abortSignal.reason is read-only in jsdom and node, https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/reason ## How did you test this change? ci green --------- Co-authored-by: Sebastian Silbermann <silbermann.sebastian@gmail.com>
## Summary [Current Yarn cache size: 555MB](https://app.circleci.com/pipelines/github/facebook/react/38163/workflows/70d0149e-b0bc-44e8-b8c9-e5c744cab89b/jobs/625334?invite=true#step-102-2) [Used Yarn cache size: 344MB](https://app.circleci.com/pipelines/github/facebook/react/38166/workflows/4825d444-1426-4321-b95b-c540e6cdc6d7/jobs/625354?invite=true#step-104-5) When we restore a global Yarn cache that's not specific to a lockfile entry (i.e. a fallback cache), we might restore packages that are no longer used. When we then run yarn install, we potentially add new packages to the cache. For example: 1. we bump a package version 2. lockfile changes 3. cache restore misses for exact key 4. cache restore hits a prefix (fallback) containing the older version, 5. yarn install adds the new version to the cache Yarn is not clearing the unused packages from the global cache. So when we then save the cache we now retain the old and new version of a package in the global cache even though the old version is no longer used. This means that the global cache grows indefinitely. Restoring the cache isn't free so CI install times will degrade over time. Either we 1. periodically prune the cache 2. just not restore anything unless we have an exact hit. The chosen tradeoff depends on the relation of commits changing deps to commits not changing deps. From my experience, we change deps rarely so I opted to only restore the cache on exact hits. ## How did you test this change? - run on `main` has 555MB of Yarn cache: https://app.circleci.com/pipelines/github/facebook/react/38163/workflows/70d0149e-b0bc-44e8-b8c9-e5c744cab89b/jobs/625334?invite=true#step-102-2 - run on this branch only has 334MB of Yarn cache: https://app.circleci.com/pipelines/github/facebook/react/38166/workflows/4825d444-1426-4321-b95b-c540e6cdc6d7/jobs/625354?invite=true#step-104-5
…26137) We're fixing the timing of layout and passive effects in React Native, and adding support for some Web APIs so common use cases for those effects can be implemented with the same code on React and React Native. Let's take this example: ```javascript function MyComponent(props) { const viewRef = useRef(); useLayoutEffect(() => { const rect = viewRef.current?.getBoundingClientRect(); console.log('My view is located at', rect?.toJSON()); }, []); return <View ref={viewRef}>{props.children}</View>; } ``` This could would work as expected on Web (ignoring the use of `View` and assuming something like `div`) but not on React Native because: 1. Layout is done asynchronously in a background thread in parallel with the execution of layout and passive effects. This is incorrect and it's being fixed in React Native (see facebook/react-native@afec07a). 2. We don't have an API to access layout information synchronously. The existing `ref.current.measureInWindow` uses callbacks to pass the result. That is asynchronous at the moment in Paper (the legacy renderer in React Native), but it's actually synchronous in Fabric (the new React Native renderer). This fixes point 2) by adding a Web-compatible method to access layout information (on Fabric only). This has 2 dependencies in React Native: 1. Access to `getBoundingClientRect` in Fabric, which was added in https://github.com/facebook/react-native/blob/main/ReactCommon/react/renderer/uimanager/UIManagerBinding.cpp#L644- L676 2. Access to `DOMRect`, which was added in facebook/react-native@673c761 . As next step, I'll modify the implementation of this and other methods in Fabric to warn when they're accessed during render. We can't do this on Web because we can't (shouldn't) modify built-in DOM APIs, but we can do it in React Native because the refs objects are built by the framework.
This is the next generation inference mode for Flow.
## Summary In jest v29, snapshotFormat default to escapeString: false(jestjs/jest#13036) ## How did you test this change? ci green
It's not really up-to-date and it's not really show casing anything we don't have elsewhere.
This is the first of a series of PRs, that let you pass functions, by reference, to the client and back. E.g. through Server Context. It's like client references but they're opaque on the client and resolved on the server. To do this, for security, you must opt-in to exposing these functions to the client using the `"use server"` directive. The `"use client"` directive lets you enter the client from the server. The `"use server"` directive lets you enter the server from the client. This works by tagging those functions as Server References. We could potentially expand this to other non-serializable or stateful objects too like classes. This only implements server->server CJS imports and server->server ESM imports. We really should add a loader to the webpack plug-in for client->server imports too. I'll leave closures as an exercise for integrators. You can't "call" a client reference on the server, however, you can "call" a server reference on the client. This invokes a callback on the Flight client options called `callServer`. This lets a router implement calling back to the server. Effectively creating an RPC. This is using JSON for serializing those arguments but more utils coming from client->server serialization.
## Hoistables In the original implementation of Float, all hoisted elements were treated like Resources. They had deduplication semantics and hydrated based on a key. This made certain kinds of hoists very challenging such as sequences of meta tags for `og:image:...` metadata. The reason is each tag along is not dedupable based on only it's intrinsic properties. two identical tags may need to be included and hoisted together with preceding meta tags that describe a semantic object with a linear set of html nodes. It was clear that the concept of Browser Resources (stylesheets / scripts / preloads) did not extend universally to all hositable tags (title, meta, other links, etc...) Additionally while Resources benefit from deduping they suffer an inability to update because while we may have multiple rendered elements that refer to a single Resource it isn't unambiguous which element owns the props on the underlying resource. We could try merging props, but that is still really hard to reason about for authors. Instead we restrict Resource semantics to freezing the props at the time the Resource is first constructed and warn if you attempt to render the same Resource with different props via another rendered element or by updating an existing element for that Resource. This lack of updating restriction is however way more extreme than necessary for instances that get hoisted but otherwise do not dedupe; where there is a well defined DOM instance for each rendered element. We should be able to update props on these instances. Hoistable is a generalization of what Float tries to model for hoisting. Instead of assuming every hoistable element is a Resource we now have two distinct categories, hoistable elements and hoistable resources. As one might guess the former has semantics that match regular Host Components except the placement of the node is usually in the <head>. The latter continues to behave how the original implementation of HostResource behaved with the first iteration of Float ### Hoistable Element On the server hoistable elements render just like regular tags except the output is stored in special queues that can be emitted in the stream earlier than they otherwise would be if rendered in place. This also allow for instance the ability to render a hoistable before even rendering the <html> tag because the queues for hoistable elements won't flush until after we have flushed the preamble (`<DOCTYPE html><html><head>`). On the client, hoistable elements largely operate like HostComponents. The most notable difference is in the hydration strategy. If we are hydrating and encounter a hoistable element we will look for all tags in the document that could potentially be a match and we check whether the attributes match the props for this particular instance. We also do this in the commit phase rather than the render phase. The reason hydration can be done for HostComponents in render is the instance will be removed from the document if hydration fails so mutating it in render is safe. For hoistables the nodes are not in a hydration boundary (Root or SuspenseBoundary at time of writing) and thus if hydration fails and we may have an instance marked as bound to some Fiber when that Fiber never commits. Moving the hydration matching to commit ensures we will always succeed in pairing the hoisted DOM instance with a Fiber that has committed. ### Hoistable Resource On the server and client the semantics of Resources are largely the same they just don't apply to title, meta, and most link tags anymore. Resources hoist and dedupe via an `href` key and are ref counted. In a future update we will add a garbage collector so we can clean up Resources that no longer have any references ## `<style>` support In earlier implementations there was no support for <style> tags. This PR adds support for treating `<style href="..." precedence="...">...</style>` as a Resource analagous to `<link rel="stylesheet" href="..." precedence="..." />` It may seem odd at first to require an href to get Resource semantics for a style tag. The rationale is that these are for inlining of actual external stylesheets as an optimization and for URI like scoping of inline styles for css-in-js libraries. The href indicates that the key space for `<style>` and `<link rel="stylesheet" />` Resources is shared. and the precedence is there to allow for interleaving of both kinds of Style resources. This is an advanced feature that we do not expect most app developers to use directly but will be quite handy for various styling libraries and for folks who want to inline as much as possible once Fizz supports this feature. ## refactor notes * HostResource Fiber type is renamed HostHoistable to reflect the generalization of the concept * The Resource object representation is modified to reduce hidden class checks and to use less memory overall * The thing that distinguishes a resource from an element is whether the Fiber has a memoizedState. If it does, it will use resource semantics, otherwise element semantics * The time complexity of matching hositable elements for hydration should be improved
When we have a key we read displayName eagerly for future warnings. In general, React should be inspecting if something is a client reference before dotting into it. However, we use displayName a lot and it kind of has defined meaning for debugging everywhere it's used so seems fine to treat this as undefined.
…acebook#26141) ## Summary I ran into some two factor certification issue and had to resume the publish script. However, this time if I confirmed the published package, it will still try to publish the same version and fail. This is not expected, and it blocks me from publishing the rest of the packages. ## How did you test this change? I re-run the publish script after the change and successfully publish the rest of the packages. ``` ? Have you run the build-and-test script? Yes ✓ Checking NPM permissions for ryancat. 881 ms ? Please provide an NPM two-factor auth token: 278924 react-devtools version 4.27.2 has already been published. ? Is this expected (will skip react-devtools@4.27.2)? Yes react-devtools-core version 4.27.2 has already been published. ? Is this expected (will skip react-devtools-core@4.27.2)? Yes ✓ Publishing package react-devtools-inline 23.1 secs You are now ready to publish the extension to Chrome, Edge, and Firefox: https://fburl.com/publish-react-devtools-extensions When publishing to Firefox, remember the following: Build id: 625690 Git archive: ****** ```
## Summary Due to facebook#25928 the attribute fixture could no longer finish since it expects at least something to render. But since Fizz currently breaks down completely on malformed `<meta>` tags, the fixture could no longer handle this. The fixture now renders valid types for `meta` tags. Note that the snapshot change to `viewTarget`` is already on `main`. Review by commit helps to understand this. Added `html[lang]` so that we test at least one standard attribute on `<html>`. `version` is obsolete so results are not that trustworthy. ## How did you test this change? With Chrome Version 109.0.5414.119 (Official Build) (64-bit) - `yarn build --type=UMD_DEV react/index,react-dom && cd fixtures/attribute-behavior && yarn install && yarn start`
## Summary In jest v27, jest-circus as default test runner (jestjs/jest#10686) ## How did you test this change? ci green
Minor version bump to get the fix for `numPassingAsserts`: jestjs/jest#13795 Test Plan: CI
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.
semverusages withcompare-versionsfor smaller bundle size (Replace DevToolssemverusages withcompare-versionsfor smaller bundle size facebook/react#26122)transformOriginprop (Add support for SVGtransformOriginprop facebook/react#26130)Summary
How did you test this change?