Summary
The published @ts-analytics/tracking package declares several runtime dependencies that nothing in the shipped tarball imports. One of them — @stacksjs/bun-router — is pinned to ^0.0.19, which is a broken publish that throws a SyntaxError on import (see stacksjs/bun-router#882).
The tracker itself doesn't import bun-router, so it doesn't crash consumers directly. But installing @ts-analytics/tracking still pulls the broken 0.0.19 into the consumer's tree, and the exact-0.0.19 pin (caret is exact on 0.0.x) forces bun-router dedup onto the broken build for anyone who also uses it directly — which has already required manual 0.0.20 overrides downstream.
Evidence (published @ts-analytics/tracking@0.1.11)
Number of files in dist/ + bin/ that import each declared runtime dependency:
| dependency | files importing it |
|---|---|
@stacksjs/bun-router (^0.0.19) | 0 — and it's the broken build |
@cwcss/crosswind | 0 |
@stacksjs/components | 0 |
@stacksjs/stx | 0 |
bun-plugin-stx | 0 |
bun-query-builder | 1 |
dynamodb-tooling | 7 |
ts-countries | 2 |
The five zero-import packages are dashboard/build tooling used by build.ts / serve.ts from source — which are not part of the published files: ["bin", "dist"].
Suggested fix
Move the five build-/dashboard-only deps to devDependencies:
@stacksjs/bun-router@cwcss/crosswind@stacksjs/components@stacksjs/stxbun-plugin-stx
This removes the broken bun-router from consumers' install trees entirely and shrinks the tracker's install footprint. Keep bun-query-builder, dynamodb-tooling, and ts-countries as runtime deps — the dist actually imports them.
If bun-router must stay a runtime dep for some reason, at minimum bump it to ^0.0.20 so it isn't the broken build.
Verification
bun run build after the change should produce byte-identical dist/ (the moved deps are build-time only), and the published tarball's runtime dependencies should drop to the three that dist imports.