compiler: add verbose logging to `react-compiler-healthcheck`

[Fausto95]

Summary

This PR adds a verbose option to react-compiler-healthcheck CLI which logs all the compiled components/hooks names and files location.

Fixes: https://github.com/facebook/react/issues/29078

Test plan

Run the react-compiler-healthcheck CLI with the —-verbose flag inside a react app and you should be able to see the compiled components/hooks names or the files path printed in green.

If there are any files that failed to compile, they will be printed in red.

[react-sizebot]

Comparing: 5e11e7fc203754cf95e27baed957c581b9ba44b8...a33ece045d7e8a1c32b07729fcf28ab8b7f7283c

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.66 kB	6.66 kB	=	1.82 kB	1.82 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	=	495.01 kB	495.01 kB	=	88.67 kB	88.68 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.67 kB	6.67 kB	=	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	=	499.81 kB	499.81 kB	=	89.36 kB	89.36 kB
facebook-www/ReactDOM-prod.classic.js	=	592.16 kB	592.16 kB	=	104.15 kB	104.15 kB
facebook-www/ReactDOM-prod.modern.js	=	568.39 kB	568.39 kB	=	100.55 kB	100.55 kB
test_utils/ReactAllWarnings.js	Deleted	64.26 kB	0.00 kB	Deleted	16.02 kB	0.00 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
test_utils/ReactAllWarnings.js	Deleted	64.26 kB	0.00 kB	Deleted	16.02 kB	0.00 kB

Generated by :no_entry_sign: dangerJS against a33ece045d7e8a1c32b07729fcf28ab8b7f7283c

[Fausto95]

@poteto, @josephsavona would appreciate if you could review this

[josephsavona]

Can you explain more about how you would use this mode? The healthcheck command is intended as a lightweight way to get a general sense of how likely it is that your app will be compatible w the compiler.

[Fausto95]

@josephsavona This mode would tell me the files that compile correctly, this would help me refactor those files and get rid of the manual useMemo & useCallbacks.

This would also help me figure out which files break the rules of React and understand the reason they failed compilation and further investigate.

[josephsavona]

Thanks for the context, we'll discuss as a team about where we want to take the tool and whether this fits in. The original idea was just to give folks a quick way to check how easy it would be to adopt the compiler.

[Frenie8006]

Just accept the PR!

[guillaumebrunerie]

This would also help me figure out which files break the rules of React and understand the reason they failed compilation and further investigate.

I think that’s what the ESLint plugin is for, rather than the healthcheck tool.

[wojtekmaj]

ESLint plugin is nowhere near as informative. It doesn't tell you when React Compiler bails out because of TODOs on RC side, or manual memoization.

[PinkaminaDianePie]

Thanks for the context, we'll discuss as a team about where we want to take the tool and whether this fits in. The original idea was just to give folks a quick way to check how easy it would be to adopt the compiler.

how easy

That's why we need a detailed list of files with the exact issues they have. When this tool tells me "issue in 100 components out of 1000" - it gives me no info, I still have 0 clue on how easy will it be to integrate anything. So I have to install eslint plugin, run the scan over my codebase, and eslint tells me that I have an issue not with 100 files, but with 6. What kind of conclusion may I have? Probably only 1 - react compiler is not even close to being production-ready, so I need to wait until the tooling around it becomes more useful. Currently, it feels like this utility is not just useless, but misleading. And until there will be no clear way to check it (like having a path to problematic file, with an eslint error there), people won't trust this tool

[Fausto95]

@wojtekmaj I appreciate the suggestions. Will apply some of them if the team decides to go with this PR.

[nikeee]

I'm considering using this tool in CI. We use Biome for linting/formatting etc, so we cannot use the eslint plugin.

There is a feature request for Biome and it looks like there isn't going to be support any time soon, since Biome is written in Rust. There exists a non-maintained, not-supported Rust implementation of RC which could be used as a base, but that would take long, too (the Rust version also has its own parse tree, query engine etc, which may not be so ideal for use in Biome). Maybe Biome will support plugins some day, so we can implement a plugin that works similar to how the eslint plugin works.

For me, using the react-compiler-healthcheck would solve most of my problems if it prints the list of affected files and returns with != 0 exit code if there were incompatible components. Or I'd have to set up eslint for CI just to invoke the eslint plugin. Wouldn't be that nice, but depending on the direction the healthcheck tool is heading, this would be a way to go.

[Fausto95]

That is a fair use case you’ve mentioned @nikeee. We are still waiting on the React team to decide whether or not they can consider merging these changes.. cc: @josephsavona

In the meantime you can use the changes in this PR and patch the package locally.

[github-actions[bot]]

This pull request has been automatically marked as stale. If this pull request is still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize reviewing it yet. Your contribution is very much appreciated.

[wojtekmaj]

Of course bump!

[olof-nord]

Adding this type of information would be great in a project where there are many components. 👍