Build, test and packaging

In short: everything builds with Bazel 9.1.0 and the Aspect JS/TS rules. npm run build is bazel build //:extension, npm run package builds //:vsix with vsce, and npm test is bazel test //.... Two in-repo macros wrap the rules: ts_library compiles a package and drops its test files, and jasmine_test compiles the tests and runs Jasmine with three helpers. One helper makes require('vscode') return an empty object, which each test fills with fakes from src/testing/ by calling installVscode. Another puts a pinned jj 0.45.1 binary on PATH. Bazel deps and visibility decide which packages may import Node or npm code. CI runs lint, a license-header check, a lockfile check and the full test suite.

1. Files

2. MODULE.bazel

3. Root targets

There is no root //:test target. Each package declares its own :tests, and npm test runs bazel test //.... Ten packages have one: //src, //src/logging, //src/utils, //src/client, //src/file_system_watcher, //src/ui/icon_theme_service, three under //src/ui/commit_graph (algorithms, components, utils) and //third_party/vscode.

4. Restricting dependencies

Inside Google the extension runs on Cider, a VS Code Web fork that can't import packages like node. The design notes ask for code to be split into interface files and implementation files, with only implementations allowed to import external-only packages, and use Bazel's deps to enforce it (docs/intro.md). A ts_project only sees the type declarations of what is in its deps, so a package without //:node_modules/@types/node can't compile an import of node:fs.

planned A TODO in //src says it should become two targets: one meant to be imported into Google that depends on little more than vscode, and one for the rest of the extension that may depend on node (source).

5. In-repo Bazel rules

ts_library

tools/bazel/typescript/defs.bzl

jasmine_test

tools/bazel/jasmine/defs.bzl

addlicense

tools/bazel/private/addlicense/addlicense.bzl

Both binaries run runner.sh, which finds the platform's addlicense through Bazel runfiles (picked by a select in private/addlicense/BUILD.bazel), refuses to run outside bazel run or without its template, changes to the workspace root and runs it over . with -f pointing at license_header.txt, adding -check for the check target. Both targets carry the template in their runfiles and pass its runfiles path as the second argument (source). The template starts with an @license line, then the copyright holder and the Apache text. The public tools/bazel/addlicense/defs.bzl only re-exports the macro.

//tools/bazel/jj

copy_jj picks the downloaded jj for the host's OS and CPU with a select over five config_settings and copies it into tools/bazel/jj/jj as an executable. Windows on arm64 has no entry here, unlike addlicense.

6. Tests and the fake VS Code API

Jasmine helpers

jasmine.json sets spec_dir to . and spec_files to **/*_test.js. Each jasmine_test loads three helpers before any spec.

installVscode

Tests call installVscode in a beforeEach (for example extension_test.ts). It fills the shared vscode object in three passes:

1. Every enum from third_party/vscode/vscode_enums.ts, 64 of them, generated from @types/vscode.
2. Classes: CancellationTokenSource, CodeLens, Disposable, Position, Range, Selection, ThemeColor, EventEmitter, LogOutputChannel, and Uri as vscode-uri's URI with its Utils merged in.
3. Fresh namespace objects: workspace, languages, commands, window, extensions.

Because the namespaces are new instances each time, every test starts clean. It returns the object typed as the fakes, so tests can reach helpers the real API doesn't have. fakeVscode() returns the same thing later, and logs() returns the fake JJ Extension output channel.

The fakes

fakes.ts re-exports 23 classes from two directories, plus fakeCommit, which builds a MutableCommit with empty defaults and overrides whatever fields the test passes. The commit-topology tests use it.

//src/testing is a ts_library over all of these (BUILD.bazel). Six test targets depend on it: //src, //src/client, //src/logging, //src/file_system_watcher, //src/ui/icon_theme_service and //src/utils. The others test plain logic and don't need the fake API.

newRepo

newRepo() is called inside a describe. Before each test it makes a fresh temporary directory, resolves it with realpath and runs jj git init there, or, given {remote}, runs jj git clone from another newRepo's root (which must be declared first, or it throws); after each test it deletes the directory. It returns the repository plus helpers that run jj in it, write or remove a file by relative path, and read the working-copy commit's change ID (source). Callers destructure the result when the describe runs, before any beforeEach, so the root path lives on a TestRepo object rather than in a string that would be captured stale (source). It runs jj through the client's subprocess helper, which is why //src/testing now depends on //src/client:subprocess_util. The SubprocessClient tests are its only users.

7. CI

Third-party actions are pinned to commit hashes. The Node version is pinned to 22 by hand, and a comment says to keep it in step with the Node that Bazel resolves.

8. Generated VS Code enums

Tests can't import the real enums, because the real vscode module only exists inside the editor. populate_vscode_enum.py generates third_party/vscode/vscode_enums.ts instead. It refuses to run unless npm run lint is clean. Then it reads node_modules/@types/vscode/index.d.ts, pulls out every export enum with its doc comment using a regex that tolerates one level of braces, writes them after the original license header and a "do not edit" line, runs npm run fix to format the file, and copies @types/vscode's LICENSE next to it.

9. Loose ends at this pin

• The .vsix ships no npm packages. vsce runs with --no-dependencies and the compiled host code is not bundled, so a runtime require of an npm package from the extension host would fail in the packaged extension. A TODO says this will matter once @parcel/watcher is used (source). At this pin nothing that reaches activate imports it.
• Stale pointer in a helper. install_global_vscode.ts tells the reader to see vscode_test.ts for the setup and teardown helpers. No such file exists; the helpers are in install_vscode.ts (source).
• Prefix match on paths. ts_library's test_ check uses startswith on the whole path, so sub/test_x.ts from a recursive glob would not be dropped. No such file exists today (source).
• No Windows arm64 jj. addlicense is fetched for six platforms but jj for five, so tests that need jj can't build there.
• Hand-synced Node version. pnpm is now read from package.json by both Bazel and CI, but Node 22 is still written in the lint workflow and kept in step with the Bazel lockfile only by a comment (_lint_run.yaml).
• One //src target. The split between Google-importable code and the rest is still a TODO, so the deps scheme isn't yet enforced for most of src/.