[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`)

[aksumustafa1625]

Summary

@sf-agentscript/agentforce@2.5.34 (current latest) cannot be imported after a clean npm install. The package's dist/ is compiled against a newer @sf-agentscript/language than the version its own package.json pins, so the import fails immediately.

This looks like a sibling of #35 (and PR #40): the scope-rewrite part appears fixed in 2.5.34 — dist/index.js now correctly imports from @sf-agentscript/language — but the same publish pipeline still emits dependency pins that don't match what dist/ was built against. Net effect is the same: the published package is broken end-to-end, just with a different error.

Reproduction

mkdir repro && cd repro && npm init -y
npm install @sf-agentscript/agentforce      # resolves 2.5.34
node --input-type=module -e "import { parse } from '@sf-agentscript/agentforce';"

Actual

SyntaxError: The requested module '@sf-agentscript/language' does not provide
an export named 'nullLiteralValidationPass'
    at .../node_modules/@sf-agentscript/agentforce/dist/index.js:354

Expected

The module imports and parse() is callable.

Root cause

@sf-agentscript/agentforce@2.5.34 → dist/index.js:354:

import { symbolTableAnalyzer, undefinedReferencePass, /* ... */,
         nullLiteralValidationPass } from "@sf-agentscript/language";

but its package.json pins the dependency exactly:

"@sf-agentscript/language": "2.5.4"

and that version does not export the symbol:

@sf-agentscript/language	exports nullLiteralValidationPass
2.5.4 (the pinned version)	❌ no
2.18.0	✅ yes

So the compiled output requires a newer language than the manifest allows. Installing @sf-agentscript/language@2.18.0 alongside it makes the import succeed, which confirms the diagnosis.

Suggested fix

1. Have the publish pipeline pin the workspace versions the artifacts were actually built against (the same step that got the scope rewrite wrong in [bug]: dist/ JS retains @agentscript/* imports after scope rewrite, breaking installed package #35 / fix publish scope rewrite for dist output #40), or simply bump the @sf-agentscript/language pin.
2. Add a post-publish smoke test that installs the packed tarball into a clean directory and does a bare import of every public entry point. Both [bug]: dist/ JS retains @agentscript/* imports after scope rewrite, breaking installed package #35 and this issue would have been caught by that single check, and it would keep the published artifact honest going forward.

Environment

• @sf-agentscript/agentforce@2.5.34 (dist-tag latest)
• resolved @sf-agentscript/language@2.5.4
• Node.js v24.15.0, npm 11.12.1, Windows 11

Notes

Workaround for anyone blocked: @sf-agentscript/parser is unaffected and can be used directly if you only need the AST — that is what I ended up doing. I am building a static authority analyzer that reads .agent authoring bundles and resolves each action's apex:// / flow:// target straight from the file.

Happy to send a PR for the smoke test if that approach is acceptable.

[aksumustafa1625]

Two updates: a correction to my own report, and a wider impact — it is not just agentforce.

Correction

This line in the issue is wrong, and I should not have written it without testing it:

Installing @sf-agentscript/language@2.18.0 alongside it makes the import succeed, which confirms the diagnosis.

It does not. Because the pin is exact ("2.5.4"), npm nests that copy under the dependent, and the nested copy wins regardless of what is hoisted at the top:

node_modules/@sf-agentscript/agentforce/node_modules/@sf-agentscript/language  -> 2.5.4   (used)
node_modules/@sf-agentscript/language                                          -> 2.18.0  (ignored)

import still fails with the same SyntaxError. I had only verified that language@2.18.0 contains the symbol and inferred the rest. Apologies — the diagnosis below is what I actually reproduced.

The fix, verified

Forcing @sf-agentscript/language@2.18.0 across the whole tree (npm overrides) does fix it:

{
  "dependencies": { "@sf-agentscript/agentforce": "2.5.34" },
  "overrides": { "@sf-agentscript/language": "2.18.0" }
}

→ import('@sf-agentscript/agentforce') succeeds.

The important consequence: the pin has to be corrected in every dependent, not just one. A partial bump only moves the error to the next package that still pins 2.5.4.

Wider impact: 3 public packages are broken, one root cause

I installed every publicly importable @sf-agentscript/* package from npm into a clean directory and did a bare import of each default entry point.

As published today:

package (npm latest)	bare import	error
@sf-agentscript/agentforce@2.5.34	❌	SyntaxError: ... does not provide an export named 'nullLiteralValidationPass'
@sf-agentscript/compiler@2.7.1	❌	TypeError: NamedBlock(...).describe(...).discriminant(...).variant(...).variantMatch is not a function
@sf-agentscript/lsp@2.3.8	❌	same TypeError (via compiler)
@sf-agentscript/language@2.18.0	✅	—
@sf-agentscript/parser@4.0.4	✅	—
@sf-agentscript/parser-javascript@2.6.0	✅	—
@sf-agentscript/types@0.2.3	✅	—

With language overridden to 2.18.0 across the tree: agentforce, compiler and lsp all import cleanly.

(@sf-agentscript/lsp-server is excluded from the table: with the stale pin it fails inside compiler, but once that is fixed a bare import throws Connection input stream is not set… — that is the server entry doing its job, not a packaging defect. Worth knowing for anyone writing an import check: it needs to be skipped or invoked with --stdio.)

Root cause (same for all three)

agentforce@2.5.34, compiler@2.7.1 and agentforce-dialect@2.13.4 each pin:

"@sf-agentscript/language": "2.5.4"

but their dist/ is compiled against a newer language. Both missing symbols are defined in packages/language/src:

• nullLiteralValidationPass — language@2.5.4 exports it: no (2.18.0: yes)
• variantMatch — occurrences in language@2.5.4 dist/: 0

agentforce fails at link time (missing named export); compiler fails at runtime the moment the module body calls .variantMatch(), which takes lsp (and lsp-server) down with it.

Inside the repo none of this is visible: packages/*/package.json correctly use workspace:*, and the workspace language is 2.18.0 and does export both symbols. The mismatch only exists in the published artifact — a language release that added API without a matching version bump for the dependents packed against it.

Why a guard, not just a bump

Bumping the pins fixes today. But this is the second release to ship an artifact that cannot be imported (#35 was the first, for a different reason in the same pipeline), and unit tests cannot see it: inside the workspace pnpm resolves siblings from source, so the packed manifest is never exercised.

One check catches the whole class: pack the packages, install the tarballs into a clean directory the way a consumer does, and import each public entry point. It fails loudly on ERR_MODULE_NOT_FOUND (#35), on a missing named export, and on a runtime TypeError from a stale sibling — i.e. on everything above.

I'm putting that together as a publish-time gate in scripts/publish.mjs (after the scope rewrite, before changeset publish) and will open a PR. Two notes I ran into while building it, in case you have a preference: it has to run after the rewrite (before it, the tarballs still reference the unpublished @agentscript/* scope), and it needs a documented skip for entries that are not bare-importable by design (lsp-server, monaco's TS source entry, the native parser-tree-sitter binding, browser bundles).