feat: add performance-testing package - #3024
Conversation
✅ Deploy Preview for flint-fyi ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Something is definitely wrong on the Flint side 😂, we're not ~1/2 the speed of ESLint. Nooope. |
|
The perf comparisons should be running equivalent rules. I'm wondering if it's because Flint rules are so much more type-heavy, it's not a fair comparison? |
What if we just compare some not-type-aware lints Flint<->core ESLint and some type-aware lints typescript-eslint<->Flint so it's comparable? Flint'll still lose against raw ESLint probably, not hopefully not TSESLint. |
|
I'm hoping we can get a roughly unbiased comparison per-axis like vlt: https://github.com/vltpkg/benchmarks |
Resolves conflicts from the comparisons -> rule-data package rename.
Pairs each Flint rule with exactly one ESLint rule instead of whichever mapping happened to sort last, so rule counts match on both sides. Points both configs at src/**/*.ts with the same ignores, declares the plugins the generated ESLint configs import, and runs Flint with --cache-ignore so Hyperfine's repeat runs do not measure a warm cache against a cold one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
Adds the return types and module ordering ESLint wants, marks the package private so the package-json rules stop asking for exports, swaps two Array constructors for Array.from, and disables performance/loopAwaits where the sequencing is deliberate. Knip treats the package the way it already treats e2e, since its dependencies are consumed by the ESLint configs it writes into generated cases rather than by its own source. Also records measurements in the README and enables the 1024-file cases. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
aaaand we're faster again. The performance measurements were very flawed. Added to the PR description. Phew! |
Co-authored-by: Amp <amp@ampcode.com> Amp-Thread-ID: https://ampcode.com/threads/T-01a01a5f-14c9-7385-a5b9-f93a5dc2f150
333c913 to
51b7e2e
Compare
We seem to have a gap in our test coverage measuring. There are no tests in this PR, yet codecov thinks everything's covered... |
michaelfaith
left a comment
There was a problem hiding this comment.
This is really cool. Nice work. I'm particularly interested in building on this to include more plugins. For instance, i'd love to be able to use this to measure the perf impact of moving the markdown language to use the Sätteri parser.
Just a bit of feedback from my side. Also it'd be nice to add some unit test coverage.
Co-authored-by: michael faith <michaelfaith@users.noreply.github.com>
michaelfaith
left a comment
There was a problem hiding this comment.
Looks good! 👍 Just a bunch of string -> function describe titles (though these could be skipped and done when we formally adopt the vitest rule (I thought we already had...)), and the failing unit tests (due to cross platform path seps)
Co-authored-by: michael faith <michaelfaith@users.noreply.github.com>
I'm happy to report we're now winning overall! Whew. But it would be interesting to maybe add this as a separate issue, I think - in case we get curious? |


PR Checklist
status: accepting prsOverview
Adds a new
packages/performance-testingthat includes a basic harness for generating different cases of (files to lint) x (rules to enable).Measurements
Hyperfine 1.20.0 on an Apple Silicon Mac, Node 24.13.1, against ESLint 10.8.0 and typescript-eslint 8.66.0:
tl;dr: we're slower than ESLint for a small number of files and rules, then quickly get progressively faster at bigger scales of files and/or rules.
❤️🔥