[ci] Fix incorrect condition #32551
Merged
[ci] Fix incorrect condition #32551
Conversation
This file contains hidden or 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
github-actions
bot
added
the
React Core Team
mofeiZ
approved these changes
Mar 7, 2025
|
Comparing: cc68006...b6e76a3 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
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.
Fixes an incorrect condition for running tests in the compiler workspace.
poteto
added a commit
that referenced
this pull request
Mar 7, 2025
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
This was referenced Mar 10, 2025
huozhi
pushed a commit
to vercel/next.js
that referenced
this pull request
Mar 11, 2025
[diff facebook/react@029e8bd6...0ca3deeb](facebook/react@029e8bd...0ca3dee) <details> <summary>React upstream changes</summary> - facebook/react#32569 - facebook/react#32567 - facebook/react#32549 - facebook/react#32545 - facebook/react#32566 - facebook/react#32551 - facebook/react#32550 - facebook/react#32528 - facebook/react#32359 - facebook/react#32536 - facebook/react#32539 </details>
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.
Fixes an incorrect condition for running tests in the compiler workspace.
Stack created with Sapling. Best reviewed with ReviewStack.