- Extend docker-compose.dev.yml with optional monitoring profile (Prometheus, Grafana, Loki) via --profile monitoring - Align dev PostgreSQL with production: pg_stat_statements + init scripts - Add scripts/seed.ts with idempotent Berlin test data (user, route, activity) - Add pnpm db:seed and pnpm dev:reset scripts - Simplify CI e2e job: replace manual docker run + BRouter setup with docker compose up --wait; add db:seed step - Improve scripts/dev.sh: Docker check, --wait health checks, --monitoring flag, seed step - Add scripts/reset-dev.sh to wipe and restart the local stack - Add .env.development.example with documented local defaults Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| check-dockerfiles.sh | ||
| dev.sh | ||
| download-dev-segments.sh | ||
| package.json | ||
| README.md | ||
| render-legal.ts | ||
| reset-dev.sh | ||
| seed.ts | ||
| tsconfig.json | ||
scripts
One-off CLIs for maintenance tasks that don't belong inside any of the apps or packages. Small enough to live in a single file each.
This folder is a pnpm workspace (@trails-cool/scripts) purely so TypeScript
has a home to resolve @types/node from — it isn't published, bundled, or
deployed. Each script is a self-contained .ts file run with
node --experimental-strip-types.
Contents
| Script | Purpose |
|---|---|
render-legal.ts |
Render a legal page (Terms / Privacy / Imprint) from its TSX source to plain markdown for docs/legal-archive/. See docs/legal-archive/README.md. |
check-dockerfiles.sh |
Bash script run in CI to verify every workspace package is COPY'd into each app's Dockerfile. |
Adding a script
- Drop the file in this folder (
.tspreferred; shell is fine for filesystem/docker glue). - For TypeScript,
tsconfig.jsonalready picks up every*.tsin this directory. - Run it with
node --experimental-strip-types scripts/<name>.ts <args>. - Document purpose + invocation in the table above.
Why not per-package scripts?
Some things (Dockerfile audits, legal-archive rendering, DB one-offs) don't belong inside any single workspace. Keeping them here avoids cross-package dependencies and keeps the app/package roots focused on product code.