Skip to content

CLI scripts

rocambille edited this page Nov 1, 2026 · 11 revisions

Summary: This page documents the productivity scripts provided with StartER via npm run commands.

What you'll learn:

  • Use the available npm scripts for development, testing, and database management
  • Run make:clone to scaffold new modules
  • Run database:reset to reset the database
  • Run database:migrate to migrate the database
  • Run database:repl to interactively query the database

Automation and utilities

StartER comes with several scripts centralizing repetitive tasks (module creation, cleaning, database synchronization, code quality checking). These commands facilitate development and ensure project consistency.

All the commands listed below can be run directly in your terminal with npm run.

Command Description
npm run make:clone Duplicates an existing module with automatic renaming
npm run make:purge Removes example modules (item, auth, user)
npm run database:reset Drops all tables and replays all SQL files (schema + migrations + seeder)
npm run database:migrate Applies un-applied migration scripts (production: preserves data)
npm run database:repl Opens an interactive SQLite REPL for querying the database
npm run install:check Verifies the installation and the database file accessibility
npm run biome:check Checks code style and quality with Biome
npm run biome:fix Automatically fixes formatting issues (Biome)
npm run types:check Checks TypeScript typing (tsc --noEmit)
npm run test Runs the full test suite with coverage (Vitest)

make:clone

Duplicates a file or folder, automatically replacing all occurrences of a name with another:

npm run make:clone -- <source> <destination> <OldName> <NewName>

For example, to create a post module from the item module:

npm run make:clone -- src/express/modules/item src/express/modules/post Item Post

Important

Why no automatic route or schema injection?

Unlike tools such as Rails (rails g scaffold) or the NestJS CLI, make:clone deliberately avoids modifying your central route files (src/express/routes.ts, src/react/routes.tsx) or database schema via automated AST transforms.

Automated code injection creates hidden side effects, can fail silently or mangle file formatting, and obscures how layers connect. Requiring explicit manual imports keeps your application's architecture intentional, transparent, and easy to parse for both human developers and AI coding agents.

Tip

The 4-step post-clone integration checklist:

After cloning a module, complete these manual steps:

  1. Database schema: declare the table in src/database/schema.sql, then rebuild with npm run database:reset.
  2. Backend routes: mount the new router in src/express/routes.ts (e.g. router.use(postRoutes): module routes already declare their full paths).
  3. Frontend routes: register page components and navigation links in src/react/routes.tsx.
  4. Automated verification: run npm run test to verify the cloned contracts and unit tests.

See Creating your first resource#track-1-the-complete-post-clone-checklist for the detailed walkthrough.

Warning

The clone trade-off (WET code)

While make:clone is fantastic for rapid, isolated prototyping, it favors a WET (Write Everything Twice) approach. If you find yourself repeatedly adding the same logic (like identical validation rules, formatting, or auth checks) across multiple cloned modules, it might be a good time to extract that shared logic into the src/express/helpers/ or src/react/helpers/ directories.

make:purge

Removes the example modules for a fresh start:

npm run make:purge

To keep authentication:

npm run make:purge -- --keep-auth

To bypass the confirmation prompt (useful in CI/CD):

npm run make:purge -- -n

This command deletes the module files and their tests, cleans up route imports, database tables and seeds (schema.sql, seeder.sql), shared types (src/types/index.d.ts) and navigation links, and automatically updates the central fixture registry (tests/fixtures/index.ts) by removing purged seeders and fixture re-exports.

Warning

This operation is reversible thanks to version control with Git.

database:reset

Drops all tables and replays all SQL files from scratch: schema.sql first, then migration scripts from src/database/migrations/ in alphabetical order, then seeder.sql.

npm run database:reset

To bypass the confirmation prompt (useful in CI/CD):

npm run database:reset -- -n

This also populates a _migrations tracking table, so you can run database:migrate afterward without conflicts.

database:migrate

Applies only un-applied SQL files to an existing database, preserving data. Designed for production deployments.

npm run database:migrate

To bypass the confirmation prompt (useful in CI/CD):

npm run database:migrate -- -n

This command:

  • Backs up the database before applying changes
  • Skips already-applied files (tracked in a _migrations table)
  • Warns if an applied file has been modified (checksum mismatch)
  • Wraps all changes in a transaction (all-or-nothing)
  • Does NOT apply seeder.sql (test data is a development concern)

See Database migrations for the full explanation.

database:repl

Opens an interactive REPL (Read-Eval-Print Loop) for querying your SQLite database directly from the terminal:

npm run database:repl

Type any SQL query and see the result immediately. Use .exit to close the interface.

> select * from user
┌─────────┬────┬─────────────────┬──────────┬────────────┬────────────────────────┬────────────┐
│ (index) │ id │ email           │ name     │ avatar_url │ created_at             │ deleted_at │
├─────────┼────┼─────────────────┼──────────┼────────────┼────────────────────────┼────────────┤
│ 0       │ 1  │ 'jdoe@mail.com' │ 'J. Doe' │ null       │ '2026-08-17T13:48:44Z' │ null       │
└─────────┴────┴─────────────────┴──────────┴────────────┴────────────────────────┴────────────┘
> PRAGMA table_info(user)
┌─────────┬─────┬──────────────┬────────────────┬─────────┬────────────┬────┐
│ (index) │ cid │ name         │ type           │ notnull │ dflt_value │ pk │
...
> .exit

Tip

This is useful for quick data inspection during development without needing an external tool like DB Browser.

install:check

Verifies that your .env file is correct and that the application can access the SQLite database file:

npm run install:check

Code quality

npm run biome:check    # Checks formatting
npm run biome:fix      # Fixes formatting
npm run types:check    # Checks typing

Testing

Run the full test suite with coverage:

npm run test

To run a single test file (fast, no coverage noise):

npx vitest run tests/express/contracts.test.ts

See Creating your first tests for a step-by-step testing guide.

Best practices and use cases

  • Clean reset: use npm run database:reset regularly during development to restart from a known and clean database state.
  • Pre-commit check: the pre-commit hook runs npm run types:check, npm run biome:check and npx vitest run --exclude tests/install. You can run them manually before committing your changes to ensure the code meets project standards.
  • Zero-Config: thanks to SQLite, none of these scripts require launching Docker beforehand, making the development cycle much faster.

See also

Clone this wiki locally