Learn Tailwind CSS - CI/CD and Build Pipelines

#Introduction

A Tailwind build on your laptop doesn't guarantee the same build runs on a server. Episode 13 covers CI/CD: running builds in an automated pipeline, leveraging caching for speed, installing Tailwind-specific linting, and deploying the results to various platforms.

The end goal is simple: every commit is verified, the generated CSS is deterministic, and deployment is no longer scary. CI isn't just "build then deploy" — it's also a quality gate before changes touch production.

#Building Tailwind on CI

The simplest GitHub Actions workflow for a Node project:

name: Build
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run build

setup-node with cache: npm stores node_modules between runs, significantly cutting install time. npm ci installs from the lockfile deterministically — unlike npm install, which can change versions.

For projects with custom build tooling, add a step that verifies the output:

npx tailwindcss -i src/styles.css -o dist/output.css --minify
test -s dist/output.css && echo "CSS OK"

test -s dist/output.css fails the pipeline if the CSS file is empty — cheap protection against builds that "succeed" but produce nothing.

#Linting with eslint-plugin-tailwindcss

Code quality doesn't stop at JavaScript. eslint-plugin-tailwindcss enforces class consistency within a project:

npm install -D eslint eslint-plugin-tailwindcss

Then register it in the ESLint flat config:

eslint.config.mjs

import tailwindcss from "eslint-plugin-tailwindcss";
 
export default [
  {
    plugins: { tailwindcss },
    rules: {
      "tailwindcss/classnames-order": "warn",
      "tailwindcss/no-contradicting-classname": "error",
      "tailwindcss/no-custom-classname": "off",
    },
  },
];

The rule tailwindcss/classnames-order forces a consistent class order (e.g., p-4 before bg-blue-500), and no-contradicting-classname catches conflicts like p-4 and p-8 together. Run it on CI so any violating PR is immediately visible.

#Deployment Strategies

The build output is static files, so the deployment options are wide:

• Vercel: native Git integration, per-PR previews, and automatic edge network.
• Netlify: a simple build command with node_modules caching, also with deploy previews.
• Static hosting: S3, Cloudflare Pages, or GitHub Pages for purely static sites.
• Edge CDN: hashed CSS files cached on the edge server nearest to users.

For platforms like Vercel, usually defining the build command and output directory is enough:

{
  "scripts": {
    "build": "tailwindcss -i src/styles.css -o dist/output.css --minify",
    "preview": "tailwindcss -i src/styles.css -o dist/output.css"
  }
}

Once CSS is generated, deploy using the same build artifacts that were tested on CI — that consistency is the key to reliability.

#Conclusion

Episode 13 closed the delivery loop: CI workflows with npm caching, CSS output verification, linting with eslint-plugin-tailwindcss, and deployment strategies to various platforms with consistent build artifacts.

Key takeaways:

• npm ci plus caching makes installs deterministic and fast.
• Verify CSS output on CI to catch empty builds.
• eslint-plugin-tailwindcss enforces class order and catches conflicts.
• Run linting on CI so violations show up in PRs.
• The same build artifacts are used for deploy — don't rebuild.
• Vercel, Netlify, or static hosting all work for static CSS.

Next, in episode 14, we'll cover performance optimization & tree-shaking — efficient content configuration for JIT, critical CSS and split CSS techniques, and how to analyze bundle size with source-map-explorer and other analyzers.