[bug]: @sf-agentscript/[email protected] (latest) still unusable — dist/ compiled against a newer @sf-agentscript/language than package.json pins (missing export nullLiteralValidationPass) #71

Activity

1. aksumustafa1625 commented on Jul 14, 2026

   

   aksumustafa1625

   on Jul 14, 2026

   Last edited by aksumustafa1625

   Author

   More actions

   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/[email protected] 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 [email protected] contains the symbol and inferred the rest. Apologies — the diagnosis below is what I actually reproduced.

   The fix, verified

   Forcing @sf-agentscript/[email protected] 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/[email protected]	❌	SyntaxError: ... does not provide an export named 'nullLiteralValidationPass'
   @sf-agentscript/[email protected]	❌	TypeError: NamedBlock(...).describe(...).discriminant(...).variant(...).variantMatch is not a function
   @sf-agentscript/[email protected]	❌	same TypeError (via compiler)
   @sf-agentscript/[email protected]	✅	—
   @sf-agentscript/[email protected]	✅	—
   @sf-agentscript/[email protected]	✅	—
   @sf-agentscript/[email protected]	✅	—

   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)

   [email protected], [email protected] and [email protected] 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 — [email protected] exports it: no (2.18.0: yes)
   • variantMatch — occurrences in [email protected] 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).
2. aksumustafa1625

   added a commit that references this issue on Jul 24, 2026

   ci(publish): fail the release if a published package cannot be imported

   ...

   e3bc3df
3. setu4993 commented on Nov 14, 2026

   

   setu4993

   on Nov 14, 2026

   Member

   More actions

   Resolved in the current releases. A fresh npm install @sf-agentscript/agentforce (2.16.1) gets dependency pins that match what dist/ was built against ([email protected], [email protected], [email protected]), and import { parse } from '@sf-agentscript/agentforce' works. Thanks for the report and the follow-up correction.
4. setu4993

   closed this as completedon Nov 14, 2026