feat(e2e): support running tests against legacy noir contract artifacts#22388
Open
benesjan wants to merge 11 commits intobackport-to-v4-next-stagingfrom
Open
feat(e2e): support running tests against legacy noir contract artifacts#22388benesjan wants to merge 11 commits intobackport-to-v4-next-stagingfrom
benesjan wants to merge 11 commits intobackport-to-v4-next-stagingfrom
Conversation
Set CONTRACT_ARTIFACTS_VERSION=<x.y.z> to transparently redirect @aztec/noir-contracts.js and @aztec/noir-test-contracts.js imports to a published version installed on demand under yarn-project/end-to-end/.legacy-contracts/<version>/. Enables verifying that contracts deployed from previous releases still work against the current stack. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The jest resolver handles redirection; the Node loader hook was dead code for our actual use case. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Previously required running scripts/ensure_legacy_contracts.mjs before jest. Moving the install into the resolver itself makes CONTRACT_ARTIFACTS_VERSION work with any entrypoint (e.g. yarn test:e2e). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
benesjan
changed the title
benesjan
force-pushed
the
jb/e2e-legacy-contract-artifacts
branch
from
ebe0705 to
4a37ed1
Compare
The previous resolver redirected the entire @aztec/noir-contracts.js package, which dragged the legacy @aztec/aztec.js along with it. That coupled the test to a moving runtime API surface and would fail at import time on unrelated breaking changes. Now the resolver lets defaultResolver run first and only swaps JSON files under .../noir-contracts.js/artifacts/ (and noir-test-contracts.js) to the legacy cache equivalents. TS wrapper classes load from the current workspace and use current aztec.js, so the test exercises only the deployed-contract artifact compatibility surface. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
mverzilli
approved these changes
Apr 8, 2026
Contributor
mverzilli
left a comment
mverzilli
left a comment
There was a problem hiding this comment.
This is a great approach 🙌
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
2 participants
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.
We need to ensure that it never happens that an already deployed contract stops working on a new release of our stack (new
Wallet/PXE). To ensure this is the case we want to run e2e tests with older contract artifacts (contract artifacts compiled with older [Aztec.nr,nargo,bb]).Now how do we achieve this?
Nico originally proposed that we would be committing the artifacts when a new release is performed. After chatting with AI I decided against this and I instead went with pulling the contract artifacts from
npmjs.comwhere they get automatically pushed on new releases as@aztec/noir-contracts.jsand@aztec/noir-test-contracts.jspackages.This has the following advantages:
The approach:
CONTRACT_ARTIFACTS_VERSION=<x.y.z>to run any e2e test against a published legacy version of@aztec/noir-contracts.js/@aztec/noir-test-contracts.js.npm installintoyarn-project/end-to-end/.legacy-contracts/<version>/(cached across runs).I think this approach turned out to be nice because it's very isolated - it's just a few files and it's jest specific.
Note on what actually gets resolved to old version
The resolver hijacks only json files in the
artifacts/dirst of@aztec/noir-contracts.jsand@aztec/noir-test-contracts.jspackages so this PR results in us using the old json artifacts but new Typescript classes (e.g. we will use newAMM.tsclass but oldamm_contract-AMM.jsonartifact).I set it up like this because that's how it's done on Ethereum as well - the json artifacts are distributed but the helper TypeScript classes are not. Hence we don't want to test backwards compatibility of the class - only of the artifacts.
How to protect against regressions?
The only thing I am worried about is that the resolver breaks with some future changes which results in the current artifacts getting resolved instead of the versioned ones and then everything happily passing in CI without us noticing. For this reason I propose that we add a build step to the contract compilation pipeline that injects the [
Aztec.nr,nargo,bb] version in the JSON contract artifact and then in the e2e test setup we add a check that asserts thatCONTRACT_ARTIFACTS_VERSIONenv var actually matches the version in the loaded JSON artifact (if the env var is set). This way we protect against this.WDYT?
Future work
CONTRACT_ARTIFACTS_VERSIONs we want to test),NxNmatrix -> running the current contract artifacts (contract artifacts currently getting released) with older versions of the stack.Why pointed at
backport-to-v4-next-staging?I pointed this PR at
backport-to-v4-next-stagingbecausev4is where we currently need this and hence where I wanted to test this. Once this gets merged I will forward-port this tov5(our merge 🚂 branch).How do I know this actually works?
Test fails successfully when run with a version that used older oracles: