brick

A personal project generator for monthly side projects. Pick a purpose (landing, api, …), get a runnable starter in under a second.

pnpm create brick api my-thing
cd my-thing && pnpm install && pnpm dev

What you get

| Template | Stack | Default port | |---|---|---| | api | Hono on Node 24, native TypeScript (no transpiler), Vitest, Biome | 3000 | | landing | Astro 5 + Tailwind v4 (via Vite plugin), Vitest, Biome | 4321 |

Every scaffolded project ships with:

• Biome for lint + format (one tool, one config).
• Vitest with a smoke test wired up.
• A typed tsconfig.json (strict + noUncheckedIndexedAccess).
• A patched package.json (name, version 0.0.0, author from your git config, MIT by default).
• .gitignore, .editorconfig, README.md, LICENSE.
• An initial git commit (unless you pass --no-git).

Usage

brick [type] [name] [options]

Positionals (both optional; missing ones become interactive prompts):
  type   landing | api
  name   target project name (kebab-case); `.` means current directory

Options:
  --license <id>     SPDX license id. Default: MIT.
                     One of: MIT, Apache-2.0, ISC, BSD-2-Clause, BSD-3-Clause.
  --in <path>        Target directory (alternative to positional name).
  --no-git           Skip git init + initial commit.
  --install          Run pnpm install after scaffolding (off by default).
  --yes, -y          Accept all defaults; never prompt.
  --version, -v      Print version and exit.
  --help, -h         Print help and exit.

Examples:

pnpm create brick                            # full interactive flow
pnpm create brick api                        # prompts for name only
pnpm create brick api my-thing               # no prompts at all
pnpm create brick api my-thing --install     # also runs pnpm install
pnpm create brick landing . --license ISC    # scaffold into the current dir

Why brick exists

Jose Manuel starts a new side project roughly every month. Most of them are Node-based — sometimes a static landing, sometimes an API, occasionally a Chrome extension or a desktop thing. The friction was always the first 30 minutes: install the framework, wire up Biome, decide which Vitest config, pick a Tailwind setup, write a sensible .gitignore, etc.

brick eliminates that 30 minutes. Pick a purpose, you're coding.

Performance

brick is fast on purpose — but the lever is not language choice. The real bottleneck in any scaffolder is pnpm install, which is the same cost in Rust, Go, or Node. brick's win is:

• Don't run install by default. --install opts in.
• Sub-second scaffold time. Tarball ≈ 8 KB minified bundled CLI + bundled templates.
• Single binary, single npm package, zero peer-dep surprises.

Repo layout

brick ships as a single npm package (create-brick). The top-level dirs split into two groups: brick's own code, and the data brick ships into your scaffolded projects.

brick's code

| Path | Role | |---|---| | src/ | brick's CLI source (TypeScript) — compiled to dist/brick.js by tsup | | test/ | brick's integration tests (scaffold.integration.test.ts, etc.) | | dist/ | built artifact (gitignored; ships in npm tarball) | | .github/ | CI workflow |

data brick ships into scaffolded projects

| Path | Role | |---|---| | templates/<id>/ | one folder per type (api, landing, …) — copied verbatim into your new project | | shared/ | universal overlay files (.editorconfig, …) — copied into every scaffold before the chosen template, so a template can override a shared file by providing its own | | licenses/ | bundled SPDX license bodies (MIT.txt, Apache-2.0.txt, …) — selected at scaffold time via --license, with {year} and {author} substituted |

The published npm tarball contains only dist/ + the three "data" dirs, plus README.md and LICENSE. Everything else (source, tests, configs) stays out via the files allowlist in package.json.

Adding a new template

1. Create templates/<id>/ with a brick.json:

   {
     "title": "Human-readable label",
     "description": "What this scaffolds.",
     "nextSteps": ["pnpm install", "pnpm dev"]
   }

2. Add a package.json, source files, README, _gitignore.
3. The template auto-registers on next install. Manifest validation is enforced.

At scaffold time:

• The shared/ overlay is copied first (so every project gets .editorconfig, etc.).
• Then the template tree is copied over it — any file in the template overrides its shared counterpart.
• Files in RENAME_ON_SCAFFOLD (_gitignore → .gitignore, etc.) are restored.
• brick.json, node_modules/, dist/, .astro/, .turbo/, .cache/ are stripped.

Roadmap

• v0.2 — brick diff: view template-vs-project drift in existing scaffolded projects (strictly a viewer — no auto-apply).
• More templates as needed (app, fullstack, extension, mac).
• Additional shared overlay files when motivated: .gitattributes, .lintstagedrc (with a git-hook runner), .nvmrc, a hardened pnpm-workspace.yaml.

License

MIT © Jose Manuel Rosa Moncayo