Repository navigation
perf(test): drop the unused MongoDB module from the test project - #57
Merged
Merged
Conversation
Upd4ting
added a commit
that referenced
this pull request
Nov 7, 2026
## Why
Goal: make the interface-auth CI and the verify-interface skill as fast
as reasonable, measured before and after each fix.
Done means: every fix is measured and lands in its own pull request
against `main` carrying before/after numbers, with the repository checks
green and the review gate passed.
The CI test job is the critical path of every run (median 31 s on recent
`main` runs, "Run tests" median 12.5 s). Most of "Run tests" is `ajs
module test` installing the test project's npm modules into
`.antelope/cache` ("Loaded 3 modules 7.3s" on the latest `main` run).
The tests themselves take 27 ms. Those installs also resolve every
transitive dependency afresh on each run, because the modules' lockfiles
were never recorded ("Recorded 2 module locks in antelope-lock/: commit
them so every install gets the same dependencies").
## What changed
- `antelope-lock/` is committed. Core replays each recorded lockfile
when it installs a module, so every run installs the same dependency
graph instead of the newest in range.
- `ci.yml` passes `cache-paths: .antelope/cache` and `cache-key-files:
src/antelope.test.ts` plus `antelope-lock/**` to `ci-node.yml`, which
restores the folder before the tests and saves it after a miss. Only the
Test job writes the folder. The Node job skips tests, so it has nothing
to save.
- AGENTS.md says how `antelope-lock/` is used and refreshed.
A restored folder never serves different dependencies than a fresh
install. Core reuses a cached module only when the version in its
`manifest.json` satisfies the pinned one and its lockfile is
byte-identical to the recorded one; otherwise it reinstalls from the
record. Checked by downgrading `@antelopejs/interface-api` inside a
cached `api` module to 0.1.0: the next `pnpm test` reinstalled it at the
recorded 0.3.0.
## Measurements
Local `pnpm test` on current `main` (after #57 and #59), 4 interleaved
rounds per side, fresh npm cache and pnpm store each round, load 13 to
15 on 16 cores:
| | CPU user+sys, median | wall range |
|---|---|---|
| `main` (no lock, no cache) | 11.0 s | 5.4 to 6.7 s |
| lock committed, no cache (a cache miss) | 4.5 s | 2.9 to 3.1 s |
| lock committed, cache restored | 2.6 s | 1.71 to 1.73 s |
No wall ranges overlap.
CI, Test job (the critical path) on GitHub runners:
| | "Run tests" step | Test job |
|---|---|---|
| `main`, 4 recent runs | 10 to 14 s, median 12.5 s | 28 to 33 s, median
31 s |
| this PR at 141216c (before the rebase onto #57), 2 runs, both restored
a cache | 5 s and 7 s | 20 s and 24 s |
| `main` after #57 and #59, 2 runs | 7 s and 9 s | 19 s and 23 s |
| this PR at 1d1798e, 1 run | 1 s | 17 s |
In those runs, "Valid module found" to "Loaded 3 modules" took 2.4 s and
3.4 s, against 10.3 s on the latest `main` run.
## Verification
- `pnpm run checks`: 8 passed, 0 failed.
- verify-interface, all four features (`antelope-lock/**` is a shared
file): smoke, tokens, cookies and request-auth journeys all PASS. No
one-way door flagged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Goal: make the interface-auth CI and the verify-interface skill as fast as reasonable, measured before and after each fix.
Done means: every fix is measured and lands in its own pull request against
maincarrying before/after numbers, with the repository checks green and the review gate passed.The CI test job is the critical path of every run (median 31 s on recent
mainruns, "Run tests" median 12.5 s). Inside that step, the test project downloads an 82 MB MongoDB binary, starts an in-memorymongod, and installs@antelopejs/mongodbfrom npm. No suite uses MongoDB:auth-jwtdeclares onlyinterface-api,interface-authandinterface-core.What changed
src/antelope.test.tsloadsauth-jwtandapionly. Themongodbmodule, theMongoMemoryServersetup and its cleanup are gone.mongodb-memory-server-coredevDependency is removed.apistays (auth-jwtdeclares@antelopejs/interface-api; withoutapithe runtime refuses to start with "Unresolved interface dependencies").The same 13 tests run and pass.
Measurements
Local, cold
pnpm test(fresh module cache, npm cache and pnpm store each round), 4 interleaved rounds per side, load 24 to 32 on 16 cores:CPU drops 41%. The local wall ranges overlap on this busy host, so the wall claim comes from CI below. Locally the MongoDB binary was already in
~/.cache/mongodb-binaries, so CI, which downloads it on every run, saves more than this table shows.CI, Test job (the critical path) on GitHub runners:
main, 4 recent runsVerification
pnpm run checks: 8 passed, 0 failed.