Re:10k Bounty for Rewriting Prettier in Rust
by liamfd on Monday November 13, 2023 @07:18AM
(#38249371)
What we did to avoid that bottleneck was just turn off the prettier eslint rule in CI and just run the `prettier --check` command they recommend in their docs.
We also have it set to only run in changed files which helps a lot.
We generally don't link pre-commit hooks for standards though, hence the CI focus. Too easy to circumvent, and I'd rather pay for an external machine to check it when it matters (pre-merge by doing it on PR commits) than block my devs when it doesn't (every time they commit to a non-main branch).
Re:10k Bounty for Rewriting Prettier in Rust
by a-ungurianu on Monday November 13, 2023 @09:25AM
(#38250422)
I’ve done some research on this in the past. The reason that is so slow is because the eslint plugin runs prettier, does a diff between the result of prettier and the real file and then converts each diff entry into a eslint issues. Most of the pain comes from this remarshaling cost
Re:10k Bounty for Rewriting Prettier in Rust
by cpojer on Monday November 13, 2023 @09:01PM
(#38258011)
I ran into the same issue and have been separating the prettier and eslint steps ever since: https://cpojer.net/posts/fastest-frontend-tooling-in-2022#es...
I _wanted_ to drop the plugin and have Prettier automatically run on as a pre-commit hook (as you suggested) but in the end I lost :) We wound up keeping the plugin and eating the slower pipeline time.
Of course there’s more overhead than just Prettier in this case—the ESLint plugin itself will be contributing towards the added runtime!—but depending on your codebase and CI machines, Prettier can definitely slow things down quite a bit. CI taking over a minute or two is a big drag on developer productivity imo.
Ideal world is that everyone is on board with code formatting as a pre-commit task that only touches modified files so it doesn’t bloat CI unnecessarily, but it’s not always possible :(