If you’re using Prettier in your projects, you might benefit from caching that’s been introduced since version 2.7 (June 2022). Let’s have a look at how it works and how much faster it runs.
Caching using the Prettier CLI
The functionality was added by @sosukesuzuki in prettier#12800, and it adds a --cache option:
prettier --write --cache ./files
You can use -w as a shorthand for --write:
# shorthand
prettier -w --cache ./files
But watch out: -c is short for --check (list unformatted files) and not for --cache.
That means that in the following command combining -c and -w, everything under ./files will be formatted without caching:
# -w takes precendece over -c
prettier -w -c ./files
That’s a good illustration why more verbose CLI options are usually better, especially in collaborative projects where someone else may have to guess what the shorthand means.
Prettier’s cache location
When you run Prettier with the --cache option, a cache (a minified JSON file) is created at ./node_modules/.cache/prettier/.prettier-cache, which contains details about files that have been formatted.
You can also set the location to somewhere else if you want:
prettier --write --cache --cache-location=.my-prettier-cache ./files
And you can evict the cache by removing the file or running Prettier without the --cache option:
rm ./node_modules/.cache/prettier/.prettier-cache
# or
prettier --write ./files
Caching strategies
There’s two options for the caching strategy; content (the file contents) or metadata, which I believe is the file’s last modified timestamp and size.
Metadata may change without file contents being changed, so caching on file contents could be slower on first run due to reading data from disk, but avoids checking and formatting files with metadata-only changes.
This appears to be inspired the ESLint caching implementation. Thanks to the open nature of the project’s development, it’s apparent that there’s minimal real-world differences in those two strategies based on cherry-picked example sources.
Don’t sweat the difference if you’re only interested in performance.
If you’re running Prettier in CI with caching enabled, you want to cache based on content as you’re likely formatting a fresh clone whose ‘last modified’ timestamps are irrelevant.
Performance impact on 14,000 files
I wrote about this before in a weekly update; this is the outcome of enabling Prettier’s cache in mdn/content.
Running prettier --write v prettier --write --cache on 14,000 files comes out like so:
# without a cache
prettier --write . 98.97s user 10.11s system 126% cpu 1:26.14 total
# with a cache
prettier --write --cache . 14.82s user 7.73s system 129% cpu 17.396 total
So in this case, we go from 90 seconds to 17 seconds, which definitely helps. And yes, I do format the whole repo occasionally when testing config changes, applying updates, and other weird scenarios.
Most authors aren’t formatting the whole repo locally very often, with pre-commit hooks running on staged files only. There’s still a lot of linting and formatting tools running during regular development due to search-and-replace changes and bulk edits, for instance.
Send it to /dev/null
Also it looks like you can shave off a precious second by sending everything to /dev/null:
prettier --write --cache . > /dev/null 14.74s user 7.29s system 134% cpu 16.424 total
Or by disabling logging:
prettier --write --cache --log-level=silent . 14.65s user 7.57s system 135% cpu 16.428 total
Job well done
Well done to the author and the maintainers on the improvements.
GitHub says there’s 9.9 million projects using Prettier, and the number is likely way higher, so I think there’s a serious chunk of developer years saved and hours of CI avoided through good old caching.
Congrats 
, and happy formatting!
See also
Published: