ESLint Config

You are a JavaScript tooling expert. The user wants to configure ESLint with custom rules for their project.

What to check first

• Run npm list eslint to verify ESLint is installed; if not, run npm install --save-dev eslint
• Check if .eslintrc.js, .eslintrc.json, or .eslintrc.yml already exists in the project root
• Run npm list eslint-config-* to see what shareable configs are available

Steps

1. Run npx eslint --init to generate an interactive ESLint config, or manually create .eslintrc.js in your project root
2. Set env object to specify your runtime (e.g., env: { browser: true, node: true, es2021: true })
3. Define extends array to inherit from a base config like "eslint:recommended" or "airbnb"
4. Add parserOptions with ecmaVersion and sourceType: "module" for modern JavaScript
5. Create a rules object and add specific rules with error levels: 0 (off), 1 (warn), 2 (error)
6. For each custom rule, use the exact rule name (e.g., "no-console": 1) and provide an array for configuration options
7. Create .eslintignore file to exclude paths like node_modules/, dist/, and build/
8. Run npx eslint . --ext .js,.jsx to test your configuration against the codebase

Code

// .eslintrc.js
module.exports = {
  env: {
    browser: true,
    node: true,
    es2021: true,
  },
  extends: ['eslint:recommended'],
  parserOptions: {
    ecmaVersion: 12,
    sourceType: 'module',
  },
  rules: {
    'no-console': ['warn', { allow: ['warn', 'error'] }],
    'no-unused-vars': ['error', { argsIgnorePattern: '^_' }],
    'semi': ['error', 'always'],
    'quotes': ['error', 'single', { avoidEscape: true }],
    'indent': ['error', 2],
    'comma-dangle': ['error', 'always-multiline'],
    'no-var': 'error',
    'prefer-const': 'error',
    'eqeqeq': ['error', 'always'],
    'curly': ['error', 'all'],
    'brace-style': ['error', '1tbs'],
    'no-multiple-empty-lines': ['error', { max: 2 }],
    'space-before-function-paren': [
      'error',
      {
        anonymous: 'always',
        named: 'never',
        asyncAr

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

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