Show the TanStack devtools on local and preview stacks behind a runtime probe #396

New issue

Closed

opened 2026-10-14 09:55:48 +00:00 by root · 5 comments

root commented

2026-10-14 09:55:48 +00:00

(Migrated from gitlab.core-project.space)

Parent

#394

What to build

The TanStack devtools appear on local and preview stacks and never in production, all from the same image. The API answers a new devtools contract procedure, GET /rpc/devtools, with the Demo Guests' labels and secrets. Those come from the seed's own definition, and the procedure answers only when DEVTOOLS_ENABLED is on; otherwise it is 404.

The front no longer strips the devtools at build time, and no longer mounts them unconditionally. It calls the probe once at boot, and only on a 200 does it lazily import and mount the devtools (Router and Query panels). Production downloads no devtools chunk. Local dev goes through the same probe.

Seam: API integration, for the probe; front view, for the gated mount; and the deploy verification, for the probe's status by stack.

Acceptance criteria

@chess/contracts has a devtools group with GET /devtools, whose output is { demoGuests: [{ label, secret }] }.
A devtools Nest module is imported only when the flag is on. /rpc/devtools returns the Demo Guests when it is on, and 404 when it is off; there is an integration test for each case.
The preview overlay sets DEVTOOLS_ENABLED=true on the app service, and production's compose does not.
verify.sh checks that /rpc/devtools answers 200 on a preview and 404 on production.
The front build keeps the devtools (removeDevtoolsOnBuild: false). The root route mounts them only after a 200 probe, through a dynamic import.
View tests: a 404 probe mounts no devtools, an erroring probe mounts none, and a 200 probe mounts them.
apps/e2e stays green with devtools on in its built target.

## Parent #394 ## What to build The TanStack devtools appear on local and preview stacks and never in production, all from the same image. The API answers a new `devtools` contract procedure, `GET /rpc/devtools`, with the Demo Guests' labels and secrets. Those come from the seed's own definition, and the procedure answers only when `DEVTOOLS_ENABLED` is on; otherwise it is 404. The front no longer strips the devtools at build time, and no longer mounts them unconditionally. It calls the probe once at boot, and only on a 200 does it lazily import and mount the devtools (Router and Query panels). Production downloads no devtools chunk. Local dev goes through the same probe. Seam: API integration, for the probe; front view, for the gated mount; and the deploy verification, for the probe's status by stack. ## Acceptance criteria - [ ] `@chess/contracts` has a `devtools` group with `GET /devtools`, whose output is `{ demoGuests: [{ label, secret }] }`. - [ ] A `devtools` Nest module is imported only when the flag is on. `/rpc/devtools` returns the Demo Guests when it is on, and 404 when it is off; there is an integration test for each case. - [ ] The preview overlay sets `DEVTOOLS_ENABLED=true` on the `app` service, and production's compose does not. - [ ] `verify.sh` checks that `/rpc/devtools` answers 200 on a preview and 404 on production. - [ ] The front build keeps the devtools (`removeDevtoolsOnBuild: false`). The root route mounts them only after a 200 probe, through a dynamic import. - [ ] View tests: a 404 probe mounts no devtools, an erroring probe mounts none, and a 200 probe mounts them. - [ ] `apps/e2e` stays green with devtools on in its `built` target.

root commented

2026-10-14 09:55:55 +00:00

(Migrated from gitlab.core-project.space)

mentioned in issue #397