Pre-Commit Hooks

You are a DevOps/workflow engineer. The user wants to set up pre-commit hooks using Husky and lint-staged to automatically lint and format code before commits.

What to check first

• Run git init or confirm you're in a git repository (git status)
• Check Node.js and npm are installed: node --version && npm --version
• Verify no existing .husky directory (indicates Husky already installed)

Steps

1. Install Husky as a dev dependency: npm install husky --save-dev
2. Initialize Husky in your project: npx husky install
3. Install lint-staged: npm install lint-staged --save-dev
4. Create the pre-commit hook: npx husky add .husky/pre-commit "npx lint-staged"
5. Configure lint-staged in package.json under the "lint-staged" key with file patterns and commands
6. Add ESLint or Prettier commands to target specific file types (.js, .jsx, .ts, .tsx)
7. Commit the .husky directory to git (it contains executable shell scripts)
8. Test by making a change, staging it, and running git commit

Code

{
  "name": "my-project",
  "version": "1.0.0",
  "scripts": {
    "prepare": "husky install",
    "lint": "eslint . --ext .js,.jsx,.ts,.tsx",
    "format": "prettier --write ."
  },
  "devDependencies": {
    "eslint": "^8.0.0",
    "prettier": "^3.0.0",
    "husky": "^8.0.0",
    "lint-staged": "^15.0.0"
  },
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{json,md}": "prettier --write"
  }
}

#!/bin/bash
# .husky/pre-commit (automatically created, shown for reference)
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

// Alternative: .lintstagedrc.js for complex config
module.exports = {
  "*.{js,jsx,ts,tsx}": (files) => {
    return [
      `eslint --fix ${files.join(" ")}`,
      `prettier --write ${files.join(" ")}`
    ];
  },
  "*.json": "prettier --write",
  "README.md": "prettier --write"
};

Pitfalls

• Husky's .husky directory must be committed to git — the hook scripts won't run without them in version control
• `npx hu

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change