Add a class for manipulating repo data

[domoscargin]

Resolves #13, resolves #12, resolves #10, resolves #9

Example action: https://github.com/alphagov/design-system-github-stats/actions/runs/12678615737

And PR: #23

Changes

Adds neostandard for linting.

• standardjs appears to be at a bit of a stalemate in terms of governance. neostandard is an open governance fork, which some of the standard team seem willing to fork back into mainline standard once the governance thing is worked out, so we can keep an eye on that.

Adds vitest for testing

• Mostly because I wanted to try vitest, and it seems nice and speedy and plays nice with ESM.
• Tests are a bit patchy at the moment, but I've done a few basic ones

Abstracts Octokit

• Adds an Octokit helper file

Adds a RepoData class

• Simplifies the build script and makes it easier to unit test things
• Responsible for storing result data, running checks and gathering the repo data

Updates the script behaviour and return data

• Now writes to file in batches, rather than each time we analysed a repo
• Uses the RepoData class extensively
• Uses a free GraphQL query to fetch initial information so the script speed is faster, and we're not close to getting to our rate limit
• Now searches for ALL package.json files, in case they're not at root, and/or there's more than one of them
  • For lockfiles, we try root and the same directory as each of the package files
• Returns a more detailed suite of dependency info
  • Will find and output all govuk-frontend versions which are direct dependencies in directDependencyVersions
  • Will find a single lockfile govuk-frontend version and output in lockfileFrontendVersion
  • Will output a latestFrontendVersion which is the highest of any collected versions.
  • If govuk-frontend is an indirect dependency, stores information about its parents in parentDependency

Dead ends

I did a lot of thinking about how to reduce the script time and API calls. The free GraphQL request for created at, pushed at and latest commit I've implemented is the biggest enhancement, and batch writing to files reduces I/O a lot. But there were some dead ends:

• I investigated using the dependency graph API, but it's a bit underbaked at the moment, and there's no easy way to get the full dependency tree for dependents. I think GitHub are working on this API though, so there may be methods in the future that allow us to skip most of our script.
• I also looked at the search API as an easier way to easily find govuk-frontend dependencies in relevant files, but the rate limit is severely restrictive (10 calls per minute for code search). Could potentially be more useable if we're doing caching, but probably not a goer.
• I tried to get the repo tree during the initial GraphQL query. Getting the root file list is a very light cost, but there's no easy way to recurse through the file structure. Whereas the REST API just takes 1 call to give you the full structure.

[domoscargin]

🐛 BUG

Parent dependencies: these are all null in the latest dataset. Suspect this is because we send the "this is an indirect dependency" examples straight to finding a lockfile version, which will generally be successful and find the govuk-frontend dependency at top level, rather than digging in the sub-levels. Probably makes sense to just fold the parent dependency in with this data, to be honest, rather than have a special path just for "indirect" dependencies.

SOLVED: 47fec86