Skip to content
Tabletop Tracker

WI-025: Put the app on a URL

WI-025: Put the app on a URL

Problem

Everything built so far is either invisible or local. The docs subsite is the only thing anyone can open in a browser; search, game detail and sign-in run on localhost:8081 behind two dev servers.

That makes progress genuinely hard to assess from the outside, which is a fair complaint and the reason this item exists.

This is not apps/web

ADR-0009 chose Astro SSR for the web app because server rendering is the free acquisition channel. This bundle is client-rendered — search engines see a shell — so it does not discharge that decision or replace that item.

It exists to make the product visible now, at the cost of one workflow.

In scope

  • expo export --platform web deployed to a Pages project, tabletop-tracker-app.
  • Preview deployments on pull requests, like the docs and unlike the API.
  • EXPO_PUBLIC_API_URL pointed at the deployed Worker.
  • A check that the public variables are actually in the bundle.

Why previews are safe here and not for the API

The API deploys only on merge, because a preview Worker binds to the real Hyperdrive and therefore production data. This bundle is static and calls the same public API a visitor would; a preview reads what anyone can read.

What went wrong while building it, and the correction

The first build produced a bundle with no API URL in it and reported success — the deployed app would have called 127.0.0.1:8787 from the visitor’s browser.

I diagnosed that as bracket notation: process.env["EXPO_PUBLIC_API_URL"] not being statically substituted where process.env.EXPO_PUBLIC_API_URL would be. That was wrong. Rebuilding both forms with every cache cleared produced byte-identical bundles.

The actual cause was mundane: the variable was not reaching that build. Proven by isolating it —

API URL in bundlebundle hash
variable unset at build time06170cee5… — matching the failed build
variable set2e61d235b…

The notation change was reverted. The check it prompted was kept, with a truthful explanation, because the underlying failure is real: an EXPO_PUBLIC_* value that does not reach the build produces a silently wrong bundle and a successful-looking deploy.

Definition of done

  • The app is reachable at a pages.dev URL.
  • The bundle contains the deployed API URL, not the localhost fallback — asserted by reading the emitted JavaScript.
  • A build whose variables did not arrive fails, rather than shipping the fallback.
  • The check stays silent when the variables are legitimately unset, so pnpm gate is unaffected.
  • Pull requests get a preview URL.
  • Gate green.

Verification

Terminal window
EXPO_PUBLIC_API_URL=https://tabletop-tracker-api.tabletop-tracker.workers.dev \
EXPO_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_... \
  pnpm --filter @tabletop/mobile build

Expect inlined: EXPO_PUBLIC_API_URL and inlined: EXPO_PUBLIC_CLERK_PUBLISHABLE_KEY.

Notes

Both variables are public by design: the Clerk publishable key identifies the instance, and the API URL is the address a browser calls. They are passed in the workflow rather than from .env because CI has no .env.

Clerk may need this origin added to its allowed origins before sign-in works from the deployed app. A development instance is usually permissive, but that is worth checking rather than assuming.