trails-cool/trails
1
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
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

1.3 KiB
Raw Blame History

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

  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.