Speeding up Prettier locally using the new –cache CLI option
prettier.ioIf your files are under version control, you already have a generic change detection mechanism that can give you a shorter list of changed files that need to be checked for formatting. For example, you can run code formatters in pre-commit hooks. Mercurial's "fix" extension rewrites commits using formatting fixes that can be focused on changed line ranges. Of course, the purpose of this --cache feature is still valid for other situations.
In between commits, the `--cache` option is still helpful because it means you can avoid running prettier on a file whose contents have changed since the last commit but not since it was last saved.
That said, formatters should be run in pre commit hooks anyway.
How do you decide what changes to restage? My experience has been that applying formatting in the pre-commit hook breaks `git add -p`.
Am I right to assume that Prettier runs single-threaded? I was never able to find an option to parallelize (and I assume it is paralellizable). Being able to speed up Prettier would improve my workflow by a lot.
You can run it through jest:
https://github.com/keplersj/jest-runner-prettier
Or run it through eslint through jest (which is what we do):
https://github.com/jest-community/jest-runner-eslint
https://www.npmjs.com/package/eslint-plugin-prettier
Either way gets you parallelism from jest. Personally I like the approach of using jest for all the "match files and run actions" logic (tests, lint etc) and then eslint for all the kinds of linting and formatting.
We then configure VSCode to lint autofix on save and get a really nice experience.
There are third party options you could try like this one (no personal experience): https://github.com/microsoft/parallel-prettier
Alternatively, it’s pretty common to only run prettier on changed files using lint-staged or pretty-quick.