Eslint Plugin Performance

[michaelfaith]

Hi 👋 I work on the Trello Platform team at Atlassian; glad to be a part of this working group, thanks for the inclusion.

For a little context, Trello is in the middle of a multi-year journey from a legacy Backbone.js mvc frontend architecture, to a React-based frontend, and while we're in this transient state, we have more than a hundred smaller React trees spread across the app. We're currently working on migrating each of those react roots off of the deprecated ReactDOM APIs that were removed in v19 (as an aside, this issue is slowing us down a bit facebook/react#29235). So we haven't been able to start testing the compiler itself out yet.

In the meantime, I wanted to connect the compiler eslint plugin, so that we can flush out any other issues that might be flying under our radar, and I encountered some concerning performance issues when adding the eslint-plugin-react-compiler to our linting setup. For additional context, the Trello frontend monorepo has a workspace for the main app, and ~160 package workspaces. So it's not crazy big, but it's large enough to where we've had to be mindful about the performance of dev tools like linting, specifically when it comes to the impact on developer experience.

So, before adding the plugin, I did some testing locally and captured timings for the two main lint executions we run in our pipelines (app and packages). I ran my tests on a Mac Book Pro with M3 Pro processor, and I recruited another dev who's using a Windows machine with WLS to provide a linux environment where they do their development. For both of our environments we saw ~23% increase in time for the lint run on our app workspace, and 13-16% increase in time for the lint run on all package workspaces.

Scope	Without Plugin	With Plugin	Delta	Environment
packages	61s	70s	+12.86%	MacOS M3 Pro
app	116s	150s	+22.67%	MacOS M3 Pro
packages	81s	96s	+15.63%	Windows WSL
app	147s	190s	+22.63%	Windows WSL

It's a pretty significant performance impact. So, I wanted to share those findings, and see if this is to be expected, or if there are any recommendations from the team for improving those times.

[josephsavona]

Thanks for posting! The amount of work that React Compiler is doing (included in eslint-plugin-react-compiler) is significantly more complex (orders of magnitude) than the average ESLint plugin, so it isn't surprising that it takes a bit more time.

A secondary factor is that currently, eslint-plugin-react-compiler has to print the ESLint AST to a string, reparse it with Babel, and then perform analysis. This is because Babel and ESLint diverged in their AST representations, making it hard to share code between these tools. Sigh.

As a workaround, you could try to ensure that the ESLint plugin is only enabled for the subset of files using React. This will avoid paying the cost of the AST conversion for all the non-React files that would get skipped anyway.