alepha@docs:~/docs/framework/cli/commands$

cat 4-verify.md | pretty

5 min read

Last commit:

#Verify Command

Run every check at once. The verify command is your pre-commit, pre-deploy, "is this thing ready?" command. If it passes, your code is solid.

#Quick Start

bash

alepha verify

Grab a coffee. When you get back, you'll know if your code is production-ready.

#Options

Flag	Description
(none)	Runs the full pipeline with no flags needed

#What It Does

The verify command runs a complete quality pipeline:

bash

alepha verify

✓ clean         Clean the project
✓ lint          Lint with oxlint, then format with oxfmt
✓ typecheck     Check TypeScript types
✓ test          Run tests with Vitest
✓ db check      Check database migrations
✓ build         Build for production
✓ clean         Clean up build artifacts

Each step must pass before the next one runs. If something fails, you'll see exactly what went wrong.

#The Pipeline

#1. Clean

bash

alepha clean

Removes the dist/ folder. Starts fresh.

#2. Lint

bash

alepha lint

Lints with oxlint and formats with oxfmt, in that order. Consistent style, no debates. Catches unused variables, suspicious patterns, import problems - and fails the run on anything in the correctness category it could not fix.

#3. Typecheck

bash

alepha typecheck

Runs tsc --noEmit. Your types must be correct. No any sneaking through, no missing properties, no incorrect function calls.

#4. Test

bash

alepha test

Runs Vitest (embedded in alepha - nothing to install). Your tests must pass. All of them.

Optional Step

This step is skipped if the project has no tests - no test/ directory and no *.spec.{ts,tsx,js,jsx} files under src/.

#5. Database Migrations Check

bash

alepha db migrations check

Verifies your Drizzle migrations are in sync with your schema.

Always Runs

This step is deliberately unconditional. It returns cleanly when the app has no database - but an app with entities and zero migrations now fails here, which is the point: that is the state that ships a server which boots green and 500s on its first query.

#6. Build

bash

alepha build

Builds your project for production using Vite. For React apps, this runs twice - once for the frontend (browser bundle) and once for the backend (server bundle). The server build is optimized to be serverless-friendly, bundling everything into a single file.

If it can't build, it can't ship. See the Build Command documentation for deployment options.

Expo Projects

This step is skipped for Expo projects (they have their own build process).

#7. Clean Again

bash

alepha clean

Removes build artifacts. Leaves your working directory clean.

#Why This Order?

The order matters:

Lint first: Format and catch issues early
Typecheck second: Types depend on clean, linted code
Test third: Tests depend on correct types
Migrations fourth: Verify schema consistency
Build last: Only build if everything else passes

Fail Fast

The pipeline is designed to fail fast. If lint fails, there's no point running tests. If types are wrong, the build will fail anyway.

#When to Run Verify

#Before Committing

bash

alepha verify && git commit -m "feat(auth): add OAuth support"

Don't commit broken code. Your teammates will thank you.

#Before Deploying

bash

alepha verify && alepha platform up --env production

Don't deploy broken code. Your users will thank you.

#In CI/CD

yaml

1jobs:2  verify:3    runs-on: ubuntu-latest4    steps:5      - uses: actions/checkout@v46      - uses: actions/setup-node@v47      - run: npm install8      - run: npx alepha verify

Your CI should run verify. If it fails, the PR doesn't merge.

#After Pulling Changes

bash

git pull && alepha verify

Make sure the latest code still works on your machine.

#Exit Codes

Exit Codes

Exit code 0 means everything passed. Exit code 1 means something failed. Use this in scripts and CI.

Scripts and CI can check the exit code:

bash

if alepha verify; then
  echo "Ready to ship!"
else
  echo "Fix the issues first"
  exit 1
fi

#Individual Commands

Don't want to run everything? Use the individual commands:

bash

# Just lint (includes formatting)
alepha lint

# Just typecheck
alepha typecheck

# Just test
alepha test

# Just build
alepha build

Full Pipeline Recommended

For final validation, always run the full verify. It's comprehensive for a reason - individual commands might miss issues that the full pipeline catches.

#Handling Failures

#Lint Failures

oxlint --fix applies every fix it can; what is left needs a human. The error messages tell you what's wrong:

txt

src/auth.ts:42:5: error eslint(no-unused-vars): Variable 'result' is declared but never used.

Fix the issue, then run verify again.

#Typecheck Failures

TypeScript errors mean your types don't match your code:

txt

src/auth.ts:42:5 - error TS2345: Argument of type 'string'
is not assignable to parameter of type 'number'.

Fix the type error. If you're stuck, tsc --noEmit gives you the full error.

#Test Failures

Read the test output. It shows exactly what failed and why:

txt

FAIL  src/auth.spec.ts > login > should return token
  AssertionError: expected undefined to equal 'abc123'

Fix your code or update the test, depending on what's actually correct.

#Build Failures

Build errors are usually TypeScript errors that typecheck missed, or runtime issues:

txt

Could not resolve './missing-file'

Check your imports. Make sure all referenced files exist.

#Speed

The full verify is fast - the oxc tools and Vite are blazing quick:

Lint: <1s (oxlint is written in Rust; even on large codebases)
Format: <1s (oxfmt, same)
Typecheck: ~5-30s (depends on project size)
Test: varies (depends on test count)
Build: ~5-30s (Vite + Rolldown)

Total: usually under a minute for most projects.

Performance Note

The slowest step is usually TypeScript's type checker. Everything else flies.

#Tips

Run verify before every PR. Make it a habit. Broken PRs waste everyone's time.

Set up a pre-commit hook. Use husky or similar to run verify automatically:

bash

alepha verify

Don't skip steps. It's tempting to skip tests "just this once." Don't. The one time you skip is the time you ship a bug.

Trust the process. If verify passes, your code is ready. If it fails, fix the issue. The pipeline exists to catch problems before users do.

Keep verify green. A failing verify should be treated as urgent. Fix it before doing anything else.