[3mdistal]

Problem

Nightly npm publishes are failing. The last one that published ran at 12:39 UTC on Oct 21. The 15:29 run failed on the stale lockfile that #7967 fixed, and all eight scheduled runs since, through 15:30 UTC on Oct 22, have failed in "Create nightly snapshot versions":

ERR_PNPM_NO_MATCHING_VERSION  No matching version found for @agent-native/core@0.215.0-nightly-20261022010010 while fetching it from https://registry.npmjs.org/
This error happened while installing a direct dependency of /home/runner/work/agent-native/agent-native/templates/community/qr

Snapshot versioning moves internal ranges to the new snapshot version. That rewrite is what keeps Dispatch's open peer range on Core (>=0.209.1) pointing at the matching snapshot, because a prerelease falls outside an open range. The community QR template (#7924) declares Core through a plain npm range instead of workspace:*, because its files get copied into other people's workspaces, so it gets the same rewrite. The lockfile refresh after versioning then looks up QR's new @agent-native/core@<snapshot> on npm, where that version doesn't exist yet. pnpm only resolves a plain range to a workspace package when link-workspace-packages is on, and it's off by default here. Dev snapshots run the same two commands and fail the same way.

Approach

Snapshot jobs refresh the lockfile with --link-workspace-packages, so an internal range that names the unpublished snapshot resolves to the workspace package. The flag is limited to the two snapshot jobs. Their refreshed lockfile is never committed, and stable releases and every other install keep pnpm's default.

What changed

• .github/workflows/auto-publish.yml: the nightly and dev snapshot steps add --link-workspace-packages to pnpm install --lockfile-only.
• scripts/ci-change-scope.ts: a change to auto-publish.yml now runs scripts/package-release-workflow.test.ts in CI, the same way a deploy-canary.yml change runs its test, so a later PR that drops the flag fails its own checks instead of the next nightly.
• scripts/package-release-workflow.test.ts: a new test builds a small workspace from the repo's real Core version, Dispatch peer range, QR range, and Changesets config, then runs changeset version --snapshot nightly. It checks that Dispatch's peer and QR's dependency both move to the snapshot, then runs each job's own install command offline and checks that QR links to the workspace Core.

Safety and operations

• What gets published: unchanged. The flag only affects how the snapshot lockfile resolves. The build that follows uses node_modules from the earlier frozen install, and QR is private, so its link never reaches npm.
• Other jobs: the stable lane and CI installs don't use the flag.
• Stop stable releases from rewriting the community QR template #8002: independent of this PR, and either can land first. Stop stable releases from rewriting the community QR template #8002 stops stable releases from rewriting QR's range. Snapshots still need this fix, because they have to rewrite internal ranges to reach the snapshot.

Verification

• Reproduced on main (11a11d9) in a scratch checkout: pnpm changeset version --snapshot nightly followed by pnpm install --lockfile-only fails with the same ERR_PNPM_NO_MATCHING_VERSION as CI. With --link-workspace-packages, the install exits 0, Dispatch's peer and QR's dependency both name the snapshot, and QR resolves to link:../../../packages/core. The same holds on Stop stable releases from rewriting the community QR template #8002's branch.
• The new test passes in about 4 seconds with CI=true. With the flag removed from the dev step, it fails with ERR_PNPM_NO_MATCHING_VERSION.
• pnpm test:package-release-workflow: 66 passed. Merged with main at 81d6f0f, after two stable releases and ci: verify generated QR pin for release merges #8046, scripts/package-release-workflow.test.ts passes 38 of 38.
• scripts/ci-change-scope.test.ts and scripts/ci-change-scope-renames.test.ts: 89 passed, including a new case for auto-publish.yml.
• node scripts/check-changeset.mjs: no changeset needed.
• CI: pending.

Review focus

• Linking workspace packages only in the snapshot lockfile refresh: is there any reason a snapshot should resolve an internal plain range from npm instead?

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; workspace linking stays limited to the snapshot lockfile refreshes.

Summary

Fixes nightly and dev snapshot lockfile refreshes by resolving unpublished internal versions from the workspace instead of npm.

• Nightly and dev snapshots resolve unpublished package ranges from the workspace.

_{Reviews (1) · Last reviewed commit: "Link snapshot-rewritten ranges to the wo..." · Reviewed by Greptile}

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[builder-io-integration]

Builder reviewed your changes — looks good ✅

Review Details

Incremental Code Review Summary

I reviewed the latest PR #8006 diff. The snapshot jobs still add --link-workspace-packages only to their lockfile refreshes, and the CI change-scope routing selects the package-release regression test when auto-publish.yml changes. The test continues to model the snapshot rewrite and checks that QR resolves to the local Core workspace package. I found no new actionable issues; the previously reported CI coverage issue remains fixed and its thread is already resolved.

Risk assessment: Standard (release workflow and CI behavior). The approach remains appropriately scoped: no stable publish path changes, and the snapshot-only lockfile refresh does not become a published artifact. No additional review comments are needed for this update.

🧪 Browser testing: Skipped — PR only modifies backend/config/docs, no UI impact.