GitHub Actions Lint-Only Workflow Builder

Generate a fast lint-check workflow to run on every PR

Creates a GitHub Actions workflow YAML that runs ESLint, a Prettier format check, and a TypeScript type-check on pull requests, with dependency caching and a configurable Node version for fast CI feedback. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Where do I put the generated workflow file?

Save it as a .yml file inside the .github/workflows directory at the root of your repository — for example .github/workflows/lint.yml. GitHub Actions automatically picks up any workflow file in that folder once it's committed to your default branch or a branch with an open PR.

The GitHub Actions Lint-Only Workflow Builder generates a ready-to-commit CI workflow that runs the three fast static checks every pull request should pass: ESLint, a Prettier format check, and a TypeScript type-check. Because these finish in seconds, a dedicated lint workflow gives contributors near-instant feedback without waiting on a full test suite.

Why a separate lint workflow?

The instinct is to put lint, test, and build in a single job. Separating lint into its own workflow (or job) has two practical advantages:

  1. Speed — lint + type-check typically completes in 30–90 seconds on a cached runner, far faster than tests. Contributors see red or green immediately, without waiting for a slow test suite.
  2. Signal clarity — when lint fails, the PR check list shows exactly which check failed. A combined job that fails only shows “build” failed; you then have to read logs to find it was a formatting issue.

How it works

You select your package manager (npm, pnpm, or yarn), the Node version to run on, and which of the three checks to include. The builder writes a workflow triggered on pull_request (and optionally push) that:

  1. Checks out the code
  2. Sets up Node with actions/setup-node@v4 using built-in dependency caching keyed on your lockfile
  3. Installs dependencies (npm ci, yarn install --frozen-lockfile, or pnpm install --frozen-lockfile)
  4. Runs each enabled check as its own named step

Splitting checks into separate steps means the Actions log shows exactly which one failed, rather than stopping at the first error.

What each check does

ESLint — static code analysis that catches real bugs (unused variables, missing await, incorrect prop types) as well as style issues. Configured by .eslintrc or eslint.config.js in your repo.

Prettier format check (prettier --check .) — verifies that every file matches the Prettier format exactly. Run prettier --write . locally to fix violations before pushing. No configuration means no debate about formatting in code review.

TypeScript type-check (tsc --noEmit) — runs the TypeScript compiler to check types without emitting output files. Catches type errors that editors may not surface, especially across file boundaries after refactoring.

The generated workflow looks like this

name: Lint
on:
  pull_request:
    branches: [main]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - name: ESLint
        run: npm run lint
      - name: Prettier
        run: npx prettier --check .
      - name: TypeScript
        run: npx tsc --noEmit

Practical tips

  • Cache is the biggest time saving. The setup-node cache stores your dependency downloads; on a repeated run with an unchanged lockfile it reduces a 60-second install to under 5 seconds.
  • Match commands to your package.json. The builder uses npm run lint by default. If your lint script is named differently, update the step.
  • Enable required status checks. In your repo’s branch protection settings, add this workflow’s check as required so PRs cannot be merged while lint is failing.
  • Run alongside tests, not instead of them. The fast lint check gives immediate feedback; keep your test job running too for full coverage.