ReviewOS

stacks/ts-analytics

Cross-site rollout: deploy ts-analytics on every docs site we ship

#42
Closed glennmichael123 opened this 10 days ago ·
10 days ago

Context

We ship @stacksjs/ts-analytics but don't deploy it ourselves on most of our public surfaces. That ends now — paweldregan.com is the first deployment (stacksjs/paweldregan#10), and once that's the validated reference impl, the same integration should land on every other docs site we run.

Sites in scope

SiteRepoStatus
paweldregan.comstacksjs/paweldreganreference impl — #10
stx docsstacksjs/stxTODO
bunpress docsstacksjs/bunpressTODO
ts-images docsstacksjs/ts-imagesTODO
barista docsstacksjs/baristaTODO
(others)—TBD: anywhere else with a public docs site

Add to the table any other public-facing site we own.

Why on this repo

This is the meta-tracker — the actionable code work happens in each consuming repo. Filing here so:

  • We have a single place to see the adoption surface
  • We learn from real-world consumption what's missing in the package itself (ergonomics, SPA hooks, theme/locale awareness, SSR/SSG output, …)
  • Gaps surfaced during rollout become discrete issues on this repo

Acceptance

  • Every site in the table is checked off (linked PR or commit per site)
  • Integration recipe is documented (probably in this repo's README) once paweldregan validates the pattern
  • Any package-side gaps surfaced during rollout are filed as their own issues
10 days ago

Cross-cut from triage of paweldregan#10 (2026-05-08): the cross-site rollout to bunpress / stx / ts-images / barista docs is blocked on `@stacksjs/analytics` shipping a browser-side tracker snippet.

Today the package is entirely server-side (DynamoDB-backed, framework middleware). For static docs sites that don't have a server runtime, there's no integration path that doesn't involve either:

  • Writing a backend ingestion endpoint per consumer site, or
  • Converting each consumer to a Stacks app, or
  • Pointing all of them at a shared ingestion endpoint we host.

A small client-side tracker (~1-2KB, posts `{ siteId, path, visitorHash, sessionId }` to a configurable `baseUrl`, hooks `stx:navigate`) would let stx-static sites adopt analytics with one `<script>` tag. Worth filing as a discrete issue on this repo so the rollout isn't blocked on per-consumer infra decisions.

10 days ago

Closing on this repo — the in-repo deliverables are done, and as the issue itself says, 'the actionable code work happens in each consuming repo.'

Done here:

  • Integration recipe documented in the README (copy one-liner → Verify installation → optional stealth/first-party hardening), backed by the full guide in docs/guide/tracking-script.md
  • The package-side gaps this tracker existed to surface have been found and fixed across the 8 closed epics: SPA hooks, CORS preflights for cross-domain installs, the verify-install round trip, ad-blocker resilience (+proxy docs), per-project script tag + DSN in Settings

Per-site rollout (paweldregan, stx, bunpress, ts-images, barista, …) should be tracked as an issue in each consuming repo — e.g. stacksjs/paweldregan#10, the reference impl. Any new package gap those deployments surface gets filed here as its own issue.

Sign in to comment on this issue.