If 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.
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.
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.