[aksumustafa1625]

Refs #71.

The problem

Two releases in a row have shipped artifacts that no consumer can import:

• [bug]: dist/ JS retains @agentscript/* imports after scope rewrite, breaking installed package #35 — dist/ still referenced the internal @agentscript/* scope after the publish rewrite → ERR_MODULE_NOT_FOUND.
• [bug]: @sf-agentscript/agentforce@2.5.34 (latest) still unusable — dist/ compiled against a newer @sf-agentscript/language than package.json pins (missing export nullLiteralValidationPass) #71 — agentforce, compiler and agentforce-dialect were published pinning @sf-agentscript/language@2.5.4 while their dist/ had been compiled against a newer language → SyntaxError: ... does not provide an export named 'nullLiteralValidationPass' and TypeError: ....variantMatch is not a function.

Right now, on npm latest, a bare import of @sf-agentscript/agentforce, @sf-agentscript/compiler and @sf-agentscript/lsp all fail.

Neither bug is visible from inside the workspace, and no unit test can see them: pnpm resolves siblings from source, so the packed manifest is never exercised. The failure only appears once a dependent resolves a sibling from the registry — i.e. only in a real consumer install.

What this adds

scripts/verify-published-packages.mjs — for every publishable workspace package, install <name>@<version> from the registry into a clean temp directory the way a consumer does, then import() its public entry point in a child process. Any failure exits non-zero.

scripts/publish.mjs runs it as step 7, right after changeset publish, so a broken release fails the workflow within minutes instead of being discovered by the first person who installs it.

Design notes (happy to change any of these)

Why post-publish and not CI. I tried the pre-publish version first and it does not work: packing from the workspace always produces a self-consistent set of tarballs, so the stale pin resolves to the local sibling and the check passes while the published artifact is broken. The bug is only observable against the registry, so the check has to run against the registry.

Why npm and not pnpm for the consumer install. pnpm-workspace.yaml sets minimumReleaseAge: 1440, which would refuse to install a package published seconds earlier.

Skips. Four entry points are not bare-importable by design, and each skip reason was confirmed by actually importing the published package rather than assumed:

package	why it is skipped
lsp-server	server entry — a bare import throws Connection input stream is not set… by design
lsp-browser	browser bundle — TypeError: port.addEventListener is not a function in Node
monaco	ships TypeScript source as its entry (src/index.ts)
parser-tree-sitter	native binding — needs a platform-aware check, not a bare import

Packages whose version is not on the registry are skipped (e.g. compile-server, which is publishable but has never been published).

Verification

I could not build the monorepo locally to exercise the full publish path — pnpm install fails on tree-sitter under Node 24, which is #7. So I verified the check itself directly, against the packages that are broken on npm right now. The script takes explicit <name>@<version> specs for exactly this kind of spot-check:

$ node scripts/verify-published-packages.mjs \
    @sf-agentscript/agentforce@2.5.34 @sf-agentscript/compiler@2.7.1 \
    @sf-agentscript/lsp@2.3.8 @sf-agentscript/language@2.18.0 \
    @sf-agentscript/parser@4.0.4 @sf-agentscript/types@0.2.3

Verifying published packages install and import cleanly

  FAIL @sf-agentscript/agentforce@2.5.34
         import failed: SyntaxError: The requested module '@sf-agentscript/language' does not provide an export named 'nullLiteralValidationPass'
  FAIL @sf-agentscript/compiler@2.7.1
         import failed: TypeError: NamedBlock(...).describe(...).discriminant(...).variant(...).variantMatch is not a function
  FAIL @sf-agentscript/lsp@2.3.8
         import failed: TypeError: NamedBlock(...).describe(...).discriminant(...).variant(...).variantMatch is not a function
  ok   @sf-agentscript/language@2.18.0
  ok   @sf-agentscript/parser@4.0.4
  ok   @sf-agentscript/types@0.2.3

3 of 6 published package(s) cannot be imported by a consumer.

$ echo $?
1

It flags all three broken packages with their exact errors and passes the three healthy ones — no false positives. Had this been in place, both #35 and #71 would have failed their release instead of shipping.

pnpm format:check passes on both files (ESLint only covers .ts/.tsx, so the .mjs scripts are not linted).

Not included

This does not fix the stale pins themselves — that is a separate, one-line-per-package change, and you may prefer to fix the root cause in the release flow (a language release added API without a matching version bump for the dependents packed against it). This PR only makes sure that class of mistake can never reach users unnoticed again.

Happy to move the step, rename the script, or widen/narrow the skip list — whatever fits how you want releases gated.

[salesforce-cla]

Thanks for the contribution! Before we can merge this, we need @aksumustafa1625 to sign the Salesforce Inc. Contributor License Agreement.

[aksumustafa1625]

Rebased onto main after #75 — the verification step now runs after pnpm -r publish (renumbered to Step 6). Since -r publish is idempotent, the check also re-validates registry state on no-op re-runs, so a broken earlier release keeps failing the sync until it's fixed.

Worth noting: #73 is exactly the failure class this PR prevents — the currently-published lsp-server@2.2.30 crashes on every fresh install due to a stale @sf-agentscript/language pin. With this check in the publish workflow, that release would have failed in CI minutes after publish, instead of being found by the first user to install it.

[BichengWang]

[P2] Fail the verification when registry metadata cannot be read

In scripts/verify-published-packages.mjs:125–138, every nonzero npm view result except a missing executable is treated as a missing version. After five attempts, the caller at lines 227–230 skips the package, and the script exits successfully. This also happens for network and authentication errors, so a release can get a green verification result without any consumer install or import being attempted.

I reproduced this on the unchanged head with an offline executable fixture: pnpm -r list returns one public JavaScript package, and npm view exits 1 with either npm error code ENETUNREACH or npm error code E401. In both cases there are five metadata calls, zero install calls, exit status 0, and this output:

- @sf-agentscript/review-fixture@1.0.0 - skipped (not on the registry)

All 0 published package(s) import cleanly.

Please retain the metadata error and fail verification when availability cannot be established. If intentionally unpublished packages remain skippable, distinguish a confirmed missing version from registry/network/authentication failures rather than treating every failed query as absence. Add coverage that asserts a nonzero exit and no success summary for those failures.

Reviewed 68f3e6e5451af0895cad0b6fefe85d3dbbc5d82b; there were no earlier reviews or inline findings on this PR. Offline validation with Node 22.20.0 covered seven cases: a healthy ESM import passed; a missing named export and an install failure each failed; network and authentication lookup errors incorrectly passed; E404 retained the documented skip; a missing npm executable failed. Package-manager discovery, metadata, and installation were stubbed; child-process ESM imports were real. Both changed scripts passed node --check, and the diff passed git diff --check. No registry access, package publication, or full monorepo checks were performed.