Skip to content
back to journal

git hooks

Ship It: The Safer, Faster Way to Commit and Push Code Without Breaking Things

Automate your pre-push workflow with Ship It for seamless code quality and consistency. Experience faster, safer deployments in JavaScript/TypeScript projects.

Ralph DuinFebruary 9, 20264 min read

<meta name="description" content="Automate your pre-push workflow with Ship It for seamless code quality and consistency. Experience faster, safer deployments in JavaScript/TypeScript projects."> <meta name="keywords" content="automated workflow, code quality, JavaScript, TypeScript, pre-push automation, Ship It, code consistency, deployment">

Pushing code shouldn’t feel risky.

Yet most developers still ship changes manually—running a few checks, skipping others, and hoping CI catches the rest. That’s how broken builds, failed tests, and messy commit histories sneak in.

Ship It fixes that.

It’s a simple, automated workflow that runs essential code quality checks before committing and pushing. One command. One path. No guesswork.


What Is Ship It?

Ship It is an automated pre-push workflow for JavaScript and TypeScript projects that enforces best practices before your code leaves your machine.

When you trigger it, Ship It:

  • Runs linting, type checks, builds, and tests
  • Pulls the latest changes with rebase
  • Stages, commits, and pushes your code safely
  • Stops immediately if something is wrong

Think of it as a guardrail for clean, confident commits in your JavaScript/TypeScript automation journey.

For a deeper dive into JavaScript automation tools, explore this overview of popular tools.


How the Ship It Workflow Works

┌──────────────┐
│   ship it    │
└──────┬───────┘
       ↓
┌──────────────┐
│ Lint (+fix)  │
└──────┬───────┘
       ↓
┌──────────────┐
│ Type Check   │
│ (tsc)        │
└──────┬───────┘
       ↓
┌──────────────┐
│ Build        │
│ (npm run)    │
└──────┬───────┘
       ↓
┌──────────────┐
│ Tests        │
│ (if exist)   │
└──────┬───────┘
       ↓
┌──────────────┐
│ Git Pull     │
│ --rebase     │
└──────┬───────┘
       ↓
┌──────────────┐
│ Stage Files  │
│ git add -A   │
└──────┬───────┘
       ↓
┌──────────────┐
│ Commit       │
│ (conventional│
│ message)     │
└──────┬───────┘
       ↓
┌──────────────┐
│ Push         │
│ origin HEAD  │
└──────────────┘

If any step fails, the process stops. No broken code gets pushed.

To learn more about version control best practices, visit our Pro Git book.


What Ship It Does (In Detail)

1. Linting

Runs:

  • npm run lint
  • If available, npm run lint:fix first

Lint errors must be fixed. Warnings are allowed.

For more on linting strategies, see ESLint documentation.


2. TypeScript Validation

Runs:

  • npx tsc --noEmit

Type errors stop everything—exactly as they should.

Explore more about TypeScript on the official TypeScript website.


3. Build Verification

Runs:

  • npm run build

If the project doesn’t build locally, it shouldn’t hit CI. This ensures your code quality remains intact.

Check out our Vite build documentation for more insights.


4. Testing (If Configured)

If a test script exists, Ship It runs:

  • npm test

Failing tests block the push to maintain high code quality.

For testing tips, see our Vitest testing guide.


5. Pull With Rebase

Runs:

  • git pull --rebase origin main

Conflicts are resolved before committing, keeping history clean.

Learn more about managing merges in our git conflict resolution guide.


6. Stage Changes

Runs:

  • git add -A

You review what’s staged and catch mistakes like environment files or secrets.

For more on staging best practices, check out git add reference.


7. Commit With Convention

Commits follow a conventional format:

type(scope): short description

Examples:

  • feat(auth): add OAuth login
  • fix(ui): resolve sidebar state bug
  • docs(readme): clarify setup steps
  • chore(deps): update axios

Subjects stay under 72 characters. Bodies are optional.

To learn more about commit conventions, see Conventional Commits spec.


8. Push

Runs:

  • git push origin HEAD

If rejected, Ship It pulls and retries.

For tips on handling push rejections, visit our git push reference.


Interactive Code Snippet

Try this example script in a safe environment to see how Ship It automates your workflow:

#!/bin/bash

set -e # Exit immediately if a command exits with a non-zero status.

# Run linting
npm run lint || (echo "Linting failed!" && exit 1)

# TypeScript validation
npx tsc --noEmit || (echo "Type check failed!" && exit 1)

# Build project
npm run build || (echo "Build failed!" && exit 1)

# Run tests if test script is available
if npm run | grep -q 'test'; then
  npm test || (echo "Tests failed!" && exit 1)
fi

# Pull latest changes with rebase
git pull --rebase origin main || (echo "Git pull --rebase failed!" && exit 1)

# Stage all changes
git add -A || (echo "Staging files failed!" && exit 1)

# Commit changes
read -p "Enter commit message: " commit_message

# Commit using the provided message
git commit -m "$commit_message" || (echo "Commit failed!" && exit 1)

# Push changes
git push origin HEAD || (echo "Push failed!" && exit 1)

Quick Reference

StepCommandOn Failure
Lintnpm run lint / lint:fixFix and retry
Typesnpx tsc --noEmitFix and retry
Buildnpm run buildFix and retry
Testsnpm testFix and retry
Pullgit pull --rebase origin mainResolve conflicts
Stagegit add -AReview files
Commitgit commit -m "..."Use convention
Pushgit push origin HEADPull and retry

The Takeaway

Ship It doesn’t replace good engineering habits. It enforces them.

If you already follow these steps, Ship It saves time. If you don’t, Ship It saves your team.

Continue exploring our resources to improve your engineering workflow.