trails/scripts/README.md
Ullrich Schäfer 374102e633
Make scripts/ a pnpm workspace + add README
render-legal.ts needs @types/node available to the TS language server
so editors (VS Code, cursor, etc.) don't complain about missing Node
globals. Without a tsconfig in this folder VS Code falls back to a
default config with no types and shows red squiggles on every
process/fs/path reference.

Solution: scripts/ becomes its own pnpm workspace (@trails-cool/scripts),
carrying @types/node as a devDep from the catalog, and a tiny
tsconfig.json with types: [node] and include *.ts. This also wires the
folder into `pnpm typecheck` as task #14, so CI type-checks scripts
alongside every other package. No runtime impact — the workspace is
never bundled or deployed.

README documents the layout, current contents (render-legal.ts +
check-dockerfiles.sh), and how to add new scripts.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-19 07:56:01 +02:00

31 lines
1.3 KiB
Markdown

# 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`](../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
1. Drop the file in this folder (`.ts` preferred; shell is fine for
filesystem/docker glue).
2. For TypeScript, `tsconfig.json` already picks up every `*.ts` in this
directory.
3. Run it with `node --experimental-strip-types scripts/<name>.ts <args>`.
4. 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.