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>
31 lines
1.3 KiB
Markdown
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.
|