Custom ESLint Rules

When to write custom rules

Standard rules don't cover your codebase's conventions? Write a custom rule to enforce them. Examples: require specific naming patterns, forbid certain libraries, enforce architectural layers.

Simple custom rule

A custom rule that forbids console.log in production code.

// .eslintrc.js - custom rule
module.exports = {
  rules: {
    'no-prod-console': {
      create(context) {
        return {
          MemberExpression(node) {
            if (node.object.name === 'console' &&
                node.property.name === 'log' &&
                !context.getFilename().includes('.test.')) {
              context.report({ node, message: 'console.log not allowed in production' });
            }
          }
        };
      }
    }
  }
};

Output:

Custom rule defined: forbids console.log in prod

Prefer plugins over rules

If your custom rule is complex or reusable, package it as an eslint-plugin and share it. For simple rules, inline them in .eslintrc.js.

Quick check

Quick check: When should you write a custom ESLint rule?

• When your codebase has unique conventions standard rules don't cover.
• For all projects.
• Only for large teams.