The ^0.2.82 stx range hoists a stale stx into every Stacks app, silently reverting fixed behaviour

[glennmichael123]

@stacksjs/bunpress@0.1.21 depends on @stacksjs/stx: ^0.2.82. Every other @stacksjs/* package in stacks@0.72.34 asks for ^0.2.197. Bun satisfies the union by hoisting an old release to the top of node_modules and giving each framework package its own nested copy:

0.2.176  node_modules/@stacksjs/stx                                  <- hoisted, what the APP resolves
0.2.198  node_modules/@stacksjs/actions/node_modules/@stacksjs/stx
0.2.198  node_modules/@stacksjs/composables/node_modules/@stacksjs/stx
0.2.198  node_modules/@stacksjs/types/node_modules/@stacksjs/stx
0.2.192  node_modules/@stacksjs/components/node_modules/@stacksjs/stx

The framework packages are all fine. The application is the only thing that resolves the hoisted copy, so the app runs a stx that no package in its own framework version accepts, 22 releases behind.

Why this is worth fixing rather than shrugging at

It cost a production outage that presented as an application bug.

stx#1927 (page actions cannot set a cookie, so they cannot sign anyone in) was fixed in 0.2.177. The app resolved 0.2.176. One release short.

The failure mode is that nothing fails. runPageAction in 0.2.176 reads result.redirect and ignores result.cookies, because that key did not exist yet:

// 0.2.176
const to = result.redirect
if (typeof to === 'string' && to) return { redirect: to, ran: true }

// 0.2.198
const cookies = serializeActionCookies(returned.cookies), to = returned.redirect
if (...) return { redirect: to, ran: true, ...(cookies.length > 0 ? { cookies } : {}) }

So sign-in POSTed, authenticated correctly, returned a correct 303 to /dashboard, and emitted no Set-Cookie at all. The browser followed the redirect unauthenticated and bounced back to /login. No install warning, no peer-dependency conflict, no runtime error, no deprecation notice. An unknown key on a returned object is not an error in JavaScript, so the whole feature was inert and silent.

Debugging it means reading the installed bundle, because the source, the docs, the closed issue and the app code all agree with each other and only the resolved artifact disagrees.

Suggested fix

Bump bunpress to ^0.2.197 so the range union has a single satisfying version and the hoisted copy matches what the framework expects.

Worth considering separately: a Stacks app that ends up with an @stacksjs/stx outside the range its own @stacksjs/* packages declare is always a bug, and buddy doctor could say so in one line. That check would have turned a multi-hour bisect into a startup warning.

Workaround for anyone hitting this

Declare stx directly in the app so the hoisted copy is the fixed one:

"dependencies": { "@stacksjs/stx": "^0.2.198" }

Environment

bun 1.3.14, macOS 15, stacks@0.72.34, linker = "hoisted" in bunfig.toml (required by better-dx).