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 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 running checks and gathering the repo data

Adds a Result class

• Stores information on the repo
• Set up as a class to allow normalisation of data for different outputs

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 directDependencies
  • Will find and output all govuk-frontend versions which are INDIRECT dependencies in indirectDependencies

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