The custom Jest test runner was originally written to install the
required extensions for the CLI integration tests. This is no longer
necessary as of https://github.com/github/vscode-codeql/pull/3232, so
we can remove all code that deals with downloading VS Code and
installing extensions. The download of VS Code will now be handled by
the base `VSCodeTestRunner`.
This also adds the script as a script in the `package.json` with the
naming such that `npm generate` will re-generate the Chromium version
file. This will ensure that the CI checks fail when the Chromium version
doesn't match the minimum supported VS Code version.
According to the DefinitelyTyped documentation, the patch version of
the type declaration package is unrelated to the library patch version.
Therefore, we should use an X-range for `@types/node` to allow
newer patch versions to be installed automatically.
This makes it possible to decode source maps containing references to
code that is not part of the extension. If it finds any such references,
it will simply not decode the source map and use the original stack
trace instead.
After the upgrade to the correct types for js-yaml, the return type
of `load` is correctly typed as `unknown`. This means that we can't
use the return value directly, but need to validate it first.
This adds such validation by generating a JSON schema for a newly
created typed. The JSON schema generation is very similar to how we do
it in https://github.com/github/codeql-variant-analysis-action.
This download download the sourcemaps from the release asset if it is
available. Unfortunately, I'm not able to test this yet because we don't
yet have any releases with sourcemaps attached. As a fallback, it will
still try to download from the workflow run.
This adds support for mapping full stacktraces in the source map
script. This allows you to pass a full stacktrace to the script and get
back a stacktrace with all original positions.
This adds a script that can be used for retrieving the original source
location when given a location in the released extension. It will
download the source map from the Actions workflow run of the release and
use the `source-map` library to extract the original location.
This uses a script to add the new `stargazers_count` and `updated_at` to
the scenario files. This is done by using the GitHub API to get the
information for each repo and then updating the scenario file.
The `updated_at` values are not completely representative since they are
the `updated_at` at time of running the script, rather than at the time
the variant analysis was run. However, this should not really matter in
practice. An alternative for scanned repositories might be getting the
creation time of the `database_commit_sha` commit.
This adds a linter for JSON scenario files which will validate the JSON
files in the scenarios directory against the TypeScript types. It will
convert the TypeScript types to JSON schema to simplify this process.
Unfortunately, this will not currently allow adding scenarios with
failing requests since the types do not allow this. Rather than removing
this validation, we should fix the types. This can be done in a follow-up
PR.
