chore(yarn-project): consume fnd artifacts as npm packages - #25097
Merged
Merged
Conversation
yarn-project's foundation JS dependencies (bb.js, bb-avm-sim, wsdb, ipc-runtime, l1-artifacts, constants-codegen, @aztec/noir-*) move from portal/file links to npm packages pinned at 6.0.0-nightly.20260804, resolved via root resolutions. BB_VERSION moves to the same release, now exactly paired with the beta.26 noir pin, and the protocol_types tag and docs example pins move with it.
With portals, tsc resolved the noir packages' internal imports from their realpath (noir/packages), where no node_modules exists, so InputMap and abiEncode's parameter types degraded to any and two latent errors never fired. The pinned npm packages resolve fully and surfaced them: - constrain convertPrivateInputsToWitnessMap's generic to InputValue - rewrite noir_codegen's value-import of the type-only InputMap in the generated types (TS1484 under verbatimModuleSyntax) until fixed upstream
…offline The npm @aztec/l1-artifacts foundry bundle references solc by version (it cannot ship a platform binary like the portal-built bundle did), so the runtime forge deploy resolves it through ~/.svm. The e2e containers run with --net=none and inherit ~/.svm from the host's home mount, but download_solc only populated it on the svm-download path - a cache hit or an existing local binary returned early and left it cold, so every L1-deploying e2e test died fetching binaries.soliditylang.org.
Reverts the previous download_solc change: l1-contracts is foundation code and will not exist in the labs repo, so its download path cannot provision solc for labs e2e tests. Instead yarn-project's build warms ~/.svm itself, reading the version from the installed @aztec/l1-artifacts bundle so it cannot drift from what the runtime forge deploy requests. The e2e containers run with no network and inherit ~/.svm from the host's home mount. On the monorepo this is normally a no-op since l1-contracts-solc has already populated the cache.
The extra argument existed because portals made node_modules content depend on noir/packages. With every noir package now npm-pinned, yarn.lock and package.json fully determine the install, and the directory argument would hard-error in the labs repo where noir/ does not exist.
nchamo
added
ci-draft
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
All alerts resolved. Learn more about Socket for GitHub. This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored. Ignoring alerts on:
|
Contributor
Author
|
@SocketSecurity ignore npm/@aztec/protocol-circuits-artifacts@6.0.0-nightly.20260804 |
fcarreiro
reviewed
Aug 4, 2026
| $(../noir-projects/labs/aztec-nr/bootstrap.sh hash) \ | ||
| $(../noir-projects/fnd/noir-protocol-circuits/bootstrap.sh hash) \ | ||
| $(cache_content_hash "^noir-projects/fnd/mock-protocol-circuits/" "^noir-projects/fnd/noir-contracts/") \ | ||
| $(cache_content_hash "^noir-projects/fnd/noir-contracts/") \ |
Contributor
There was a problem hiding this comment.
Arghh, we should find a way to get rid of this one
Contributor
Author
There was a problem hiding this comment.
Agreed, I'll work on that next
Collaborator
Flakey Tests🤖 says: This CI run detected 1 tests that failed, but were tolerated due to a .test_patterns.yml entry. |
fcarreiro
added a commit
that referenced
this pull request
Aug 7, 2026
## Summary - #25098 publishes the CDB server bindings as `@aztec/cdb`, so the simulator no longer needs to generate them. This drops the local codegen and consumes the package, following #25093 for the other foundation packages. - The published output is byte-identical to what `ipc-codegen` produced here, and `cdb_ipc_server.ts` now matches `next`'s already-migrated version exactly. Also removes the `generate` script, its `build:fuzzer` call, the `simulator` entry in the bootstrap generate fan-out, and the now-inputless `ipc-codegen`/`cdb_schema.json` patterns in the yarn-project build hash. - Bumps the labs pin to `6.0.0-nightly.20260807`, because `@aztec/cdb` does not exist at the nightly this branch was previously pinned to. #25097's three artifact packages move with it, since `check_pin_drift` requires every `@aztec/*` resolution to match `BB_VERSION`. The noir submodule and both pinned Noir crates are byte-identical across the bump.
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
3 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.
Motivation
Stacked on #25093, which moves yarn-project's foundation dependencies from source portals to pinned npm packages. Its follow-up list names what is left: the TypeScript generators still copy compiled Noir artifacts straight out of
noir-projects/fnd, a directory the labs repo will not have.The change
The generators now read the artifact packages published by #25075 instead of the
fndtarget directories:noir-protocol-circuits-typestakes the circuits and the twoprivate_kernel_reset_*.jsonfiles from@aztec/protocol-circuits-artifactsivc-integrationtakes the mock circuits from@aztec/mock-protocol-circuits-artifactsprotocol-contractsandaztec.jstake the contract artifacts andprotocol_contracts.jsonfrom@aztec/protocol-contracts-artifactsPinning follows the convention #25093 established:
0.1.0-dummyin the workspace manifests, the real version in the rootresolutionsblock.check_pin_driftgains a loop over that block, so all 22 first-party pins are now checked againstBB_VERSIONinstead of only the Nargo tags and the docs example; the ones #25093 adds were previously unchecked.With the artifacts arriving as packages, yarn-project's build hash no longer needs its fnd protocol-circuits and mock-protocol-circuits inputs, which resolves the TODO sitting on them. The fnd noir-contracts pattern stays, for a reason the old comment did not give:
check_oracle_versionreadsORACLE_VERSION_MAJORout of aztec_sublib'sversion.nrduring the build, so dropping it would let an oracle-version bump be served from a stale cache.Verification
Every generated file was compared against the
6.0.0-nightly.20260804release of the same package, which CI built through the old source-reading path.vk_tree.ts,private_kernel_reset_data.ts,private_kernel_reset_types.ts,client_artifacts_helper.tsandprotocol_contract_data.tsare byte-identical, so VK hashes, contract class ids and canonical addresses are unchanged. The artifacts themselves match the checked-in pins exactly: 82/82 circuits, 11/11 mocks.One deliberate difference: the generated aztec.js protocol-contract wrappers now carry
aztecVersion: '6.0.0-nightly.20260804'rather than'dev', because published artifacts are version-stamped at release time and locally compiled ones are not. Nothing hashes or branches on that field.