Prettier package not actually being cached

[benpickles]

With the current configuration Prettier seems to be installed on every run - which can been seen from the output:

npx: installed 1 in 5.166s

Prettier isn't explicitly being installed (it's surprising that actually installing the dependencies isn't included in the actions/cache docs) but it turns out that npx will automatically install the package for the specified command (it actually guesses the package name from the name of the command). I'm not sure where Prettier ends up being installed but it doesn't appear to be in ~/.npm according to the post-cache output (or ./node_modules when I tested locally):

Cache hit occurred on the primary key Linux-npm-565329898f77080e58b14d45cf816ab94877e6f2ece9d395c369c533548a7ee7, not saving cache.

I think there are a couple of approaches to tackling this, you could manually install/cache Prettier within the action, or add a package.json with Prettier. I would go with the latter because it's a more standard and maintainable approach and it will also ensure that, along with CI, anyone working on the project will run the same version of Prettier (you'll also get Dependabot JavaScript updates).

I've tested the package.json approach on a branch and am happy to turn it into a pull request if you fancy.

[simonw]

Oh that's so frustrating! I was worried about that - I spotted a few runs that seemed faster and hoped that it meant that the package was coming out of the ~/.npm cache, but evidently that's not the case.

You've convinced me that Datasette itself should have a package.json - the Dependabot argument is a really good one.

But... I'd really love to figure out a general pattern for using npx scripts in GitHub Actions workflows in a cache-friendly way. I have plenty of other projects that I'd love to run Prettier or Uglify or puppeteer-cli in without adding a package.json to them.

Any ideas? The best I can think of is for the workflow itself to write out a package.json file (using echo '{ ... }' > package.json) as part of the run - that way the cache should work (I think) but I don't get a misleading package.json file sitting in the repo.

[simonw]

And @benpickles yes I would land that pull request straight away as-is. Thanks!

[simonw]

Also welcome in that PR would be a bit of documentation for contributors, see #1167 - but no problem if you leave that out, I'm happy to add it later.

[benpickles]

I somewhat share your reluctance to add a package.json to seemingly every project out there but ultimately if they're project dependencies it's important they're managed within the codebase.