#1915 · stacks/stx

stx codemod and stx typecheck both fail on every invocation from the published package:

$ bunx stx codemod "resources/views/**/*.stx"
ReferenceError: awaitPromise is not defined

Reproduces on a one-line throwaway file, so it is not input-dependent. @stacksjs/stx@0.2.170, via node_modules/.bin/stx -> ../@stacksjs/stx/dist/cli.js.

Cause

The source is correct — packages/stx/bin/cli.ts:1852:

const { Glob } = await import('bun')

The bundler inlines the bun builtin import to await Promise.resolve(globalThis.Bun), which is a fine rewrite, but the space between await and Promise is lost. dist/cli.js contains:

{Glob:K}=awaitPromise.resolve(globalThis.Bun)

awaitPromise is never defined anywhere in the file — grep -c awaitPromise dist/cli.js returns 2, and there is no declaration for either. Both occurrences are the same pattern, in the two commands that use it:

line 27096, the typecheck action
line 27101, the codemod action

So both commands are 100% broken in the shipped artifact while the source and its tests are fine. Anything that runs the CLI from a source checkout works, which is presumably why it has gone unnoticed.

Impact

stx codemod is the tool stx#1843 shipped to measure primitive adoption, and it cannot be run by any consumer installing from npm. Same for stx typecheck.

Workaround until a release: invoke the CLI from a checkout.

bun /path/to/stx/packages/stx/bin/cli.ts codemod --rule tooltip "…/**/*.stx"

Suggested check

Worth a smoke test that actually executes each CLI command's action from the built dist/, rather than testing the source only. A bundler mangling an await into an identifier is invisible to any test that imports the source.

Found while trying to run the codemod against stacksjs/stacks#2290.

Already fixed — you are on 0.2.170, and the fix shipped in 0.2.171 (7b7406c146, filed as #1896).

bunx @stacksjs/stx@0.2.171 …   # or: bun add -d @stacksjs/stx@latest

Verified against the published tarball rather than the source, since "the artifact differs from the source" was the entire point of the original report:

published 0.2.171:  awaitPromise occurrences: 0   globalThis.Bun.Glob: 2
published 0.2.170:  awaitPromise occurrences: 2

Your diagnosis matched the fix exactly, including both call sites and why a source checkout hides it. Bun is a global, so the dynamic import bought nothing and both sites now use globalThis.Bun.Glob.

The gap it exposed is now guarded: nothing was running the built CLI. Every test imported from src, where the construct is valid, and awaitPromise parses cleanly so inspecting the artifact would not have caught it either. There are now three checks that fail if it comes back — the fused identifier by name, both commands executed end to end, and the construct itself in the source. They skip rather than fail when dist is absent, so a fresh clone does not go red.