Problem: Recently, our GitHub Action that formats the code started failing. The earliest instance was this.
Diagnosis: The error log shows that our set of dependencies (package.json -> "dependencies") cannot be installed with the node version that is chosen by default by GitHub Action (v18.14.2).
Possible solution 1: We don't actually have to npm ci; we can npm install prettier only. This has the benefit of speeding up the "install" stage of the Action. But, nitpick, I'd prefer to specify all dependencies in package.json, and not have that mention of prettier hanging around in a github action file.
Possible solution 2: We can and should update our dependency versions -- especially because there are some warnings. But, in general, upgrading dependencies can be a breeze or a headache. I didn't want to tackle it in this PR.
Possible solution 3: We specify the node version to be used by GitHub Action. This is the solution impl'd by this PR.
In addition, I've decided to let our GitHub Action only check for formatting issues, and not commit modifications. This simplifies the Action. To ask developers to bear the inconvenience of manually running the formatter and checking the code is reasonable.
The first commit implements the change to the Action; the second commit runs the formatter. The first commit fails the Action; the second commit makes it pass.
Problem: Recently, our GitHub Action that formats the code started failing. The earliest instance was this.
Diagnosis: The error log shows that our set of dependencies (package.json -> "dependencies") cannot be installed with the node version that is chosen by default by GitHub Action (v18.14.2).
Possible solution 1: We don't actually have to
npm ci; we cannpm install prettieronly. This has the benefit of speeding up the "install" stage of the Action. But, nitpick, I'd prefer to specify all dependencies in package.json, and not have that mention ofprettierhanging around in a github action file.Possible solution 2: We can and should update our dependency versions -- especially because there are some warnings. But, in general, upgrading dependencies can be a breeze or a headache. I didn't want to tackle it in this PR.
Possible solution 3: We specify the node version to be used by GitHub Action. This is the solution impl'd by this PR.
In addition, I've decided to let our GitHub Action only check for formatting issues, and not commit modifications. This simplifies the Action. To ask developers to bear the inconvenience of manually running the formatter and checking the code is reasonable.
The first commit implements the change to the Action; the second commit runs the formatter. The first commit fails the Action; the second commit makes it pass.
If approved, please go ahead and merge.