`src/main.ts` includes the import:
```javascript
import { RequestError } from '@octokit/request-error'
```
However, we weren't explicitly requiring this in `package.json`. It was implicitly coming in via `@actions/github` import, but best to be explicit about it.
Discovered via:
```shell
npm install -g npm-check
npm-check
```
Which reported the following error:
```
@octokit/request-error 😟 PKG ERR! Not in the package.json. Found in: /src/main.test.ts, /src/main.ts
```
Note: There is a newer `v6` version of `@octokit/request-error` available. However, it threw a type error due a breaking change. So for now I only bumped to the `v5` version, and we can fix the upgrade later. It's a step in the right direction to at least make this import explicit.
`src/main.ts` includes the import:
```javascript
import { RequestError } from '@octokit/request-error'
```
However, we weren't explicitly requiring this in `package.json`.
It was implicitly coming in via `@actions/github` import, but best
to be explicit about it.
Discovered via:
```shell
npm install -g npm-check
npm-check
```
Which reported the following error:
```
@octokit/request-error 😟 PKG ERR! Not in the package.json. Found in: /src/main.test.ts, /src/main.ts
```
Note: There is a _much_ newer version of `@octokit/request-error` available.
However, that threw some type errors due to breaking changes.
This `2.1.0` version was already pinned as a transitive dependency
in `package-lock.json`, so I went with that for now.
While reviewing some logs, I noticed the following:
```shell
added 1 package, changed 30 packages, and audited 382 packages in 6s
58 packages are looking for funding
run `npm fund` for details
found 0 vulnerabilities
```
While I'm not against security, nor supporting OSS maintainers (I
co-maintain 10+ projects myself!), I am against noisy logs that add no
value.
So let's silence these:
1. When they appear in CI, they add no value.
1. We've got our own security tools for vulnerable deps, which we rely
on instead of `npm audit` results.
1. When I'm skimming logs looking for debug information, these just get
in my way.
1. There may be a speed boost if the audit/fix metadata requires an additional API call,
and silencing actually skips that rather than merely silencing it.
There's multiple ways to silence these: https://benjamincrozat.com/disable-packages-are-looking-for-funding
Originally I tackled this by adding `--no-audit --no-fund` flags, but
there's a lot of different entrypoints and workflows that call `npm ci`
or `npm install`. Even if I do manage to get them all, there's always a
risk someone will come along later and add another entrypoint. So that's
why I went the `.npmrc` route.
After this change, the logs are much better:
```shell
added 1 package, changed 30 packages, and audited 382 packages in 6s
```
We'd like to start releasing monthly so that we don't fall quite so far behind... based on past commit frequency, most of these releases will only contain merged :dependabot: PR's bumping our deps, but this way we find out quickly if a dep breaks our action.
We're about to cut a new major version of this action,
and we don't anticipate any further releases of the `v1`
line.
So I simply updated the automation to float the `v2` tag.
Technically we could make it so it intelligently looks at
the release number and updates the appropriate tag, but
that'd be a bit more work and we don't need that complexity
in this repo right now given our very infrequent cadence of
bumping major versions.
As explained in a [code comment](f2f0ad1522/.github/workflows/release-move-tracking-tag.yml (L11-L28)):
```
# We have a choice - defensiveness vs convenience:
# 1. Be defensive by filtering if the release doesn't look like a normal
# version, or if it's a patch release to an older version... the logic
# gets tricky quickly. Easiest way to be 100% sure is stop running this
# on `release` and instead require a human to manually run this workflow
# after they tag a release.
# 2. Minimize the upfront hassle by assuming every release is a normal
# version release and the latest one. Today both are resoundingly true
# as this repo isn't that active/busy, so we don't worry about
# multiple release branches, pre-releases, etc.
#
# For now I've gone with option 2, as it is much more convenient and if we
# typo something during a release it's easy to fix by immediately tagging a
# correct release. And if we don't notice the typo, well, in that case
# requiring a human to manually run the workflow wouldn't have protected us
# either, we'd have had to filter by only things that look like versions.
# Anyway, for now this is good enough, and if it gets to be a problem down
# the road we increase the robustness of this.
```
* Upgrade from node16 to node20
node16 is now EOL
* Ugrade node and npm versions
* Use the GitHub Actions reporter to stop failing on core.setFailure tests
* `npm >= 10` requires `node >= 20.5.0`
Co-authored-by: Paul <schuette.paul@gmail.com>
---------
Co-authored-by: Jeff Widman <jeff@jeffwidman.com>
Co-authored-by: Paul <schuette.paul@gmail.com>
