Use an action `cache` to improve performance

[nuke-web3]

https://github.com/actions/cache#cache-action can be used to store the dprint cache in this check action, that radically lessens the load for the action.

As a minimal example: this setup is working nicely for me so far. I have yet to see if the intended behavior (clear cache on update to *dprint.json) is working, but that seems like the most logical thing to signal an update.

The question is, should this action itself allow for use of a cache, optionally? IMHO yes, but perhaps just the example of using the action should include a cache.

[nuke-web3]

here is an example of the cache working as expected on update to .dprint.json : https://github.com/Polkadot-Blockchain-Academy/pba-book/actions/runs/6125618243/job/16627953315#step:4:9

Maybe a tiny win, but a win IMHO 😁

[dsherret]

Yeah, caching can lead to a huge performance improvement (ex. https://david.deno.dev/posts/faster-prettier-with-dprint/)

I just did a release of dprint that fixes a caching issue (https://github.com/dprint/dprint/releases/tag/0.41.0) on GH actions. There is a PR here about updating the docs to indicate how to do caching dprint/dprint#740 but building it directly into the action would probably be good. I'm not sure if it should be turned on by default though. I think probably, with a major release of the action.

[nuke-web3]

👋 checking in here @dsherret - is cahce now integrated or is a manual wrapping needed? (like lychee uses for example)

[dsherret]

There's no built-in caching at the moment, but it would be nice to have this.

Here's an example implementation in Deno if someone has the time to work on this:

• feat: add built-in caching via inputs denoland/setup-deno#89
• feat: include a hash of deno.lock files in the cache key automatically denoland/setup-deno#98 (we'd want to have the dprint.json/dprint.jsonc/etc config files automatically in the cache key)