Keeping back in `"es6"` is causing an issue over in a Dependabot PR where
another library wants to use newer Javascript features.
The reason `"es6"` was the previous target is because GitHub actions
used to use node 12, which didn't support some of the newer versions.
But now that GitHub Actions is on Node 20, which supports `"es2022"`,
it's safe to let Typescript compile using this much newer syntax.
This bumps to ESLint 9:
* Bump the main `eslint` package to v9
* Remove the `eslint-config-standard` package as it doesn't yet support
ESLint 9 and doesn't appear to be actively maintained... I considered
some of the alternatives, but they've got some drama attached (https://github.com/standard/standard/issues/1948)
so it seemed simplest for now to not worry about replacing it. This is
a linter, so it's easy to switch to a different config if we want to
later.
* Migrate to the new [Flat config format](https://eslint.org/docs/user-guide/configuring/configuration-files#using-the-flat-format).
`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.
```
