# Custom ESLint Rules — ESLint + Prettier

Source: https://www.geekswithgeeks.com/en/eslint-prettier/eslint-prettier-15

> Write custom rules for domain-specific linting needs.

## 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.

```javascript
// .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

**Quiz:** When should you write a custom ESLint rule?

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

*Answer:* When your codebase has unique conventions standard rules don't cover.. Custom rules automate enforcement of architectural or style decisions unique to your team.