Why You Might Need a Custom Rule

ESLint comes with hundreds of built-in rules, plus thousands more via plugins. But sometimes that’s still not enough.

✅ Maybe your team has a unique naming convention
✅ Maybe you want to restrict a specific pattern
✅ Maybe you need to enforce a team-specific coding guideline

In those cases, writing a custom rule is the best way to codify your standards and share them across projects. Let’s build a real-world example from scratch.

Example: Enforcing Allowed Console Methods

Suppose your team allows console.warn and console.error, but bans console.log in production code. No off-the-shelf rule does exactly that. So you’ll make your own.

1. Setting Up an ESLint Plugin

First, create a new workspace:

Create a folder for your rules:

2. Writing the Custom Rule

In lib/rules/no-console-log.js:

✅ This uses an AST visitor for MemberExpression nodes to spot console.log calls.
✅ If found, it reports them with a custom message.

3. Wiring Up the Plugin

In index.js:

Then in your project (let’s say a React app or Node app), install this plugin locally:

and in your .eslintrc.json:

{
  "plugins": ["team-rules"]

Now any use of console.log in the project will trigger a lint error! 🎉

Common Questions

Q: Could I make the banned methods configurable?
Absolutely. Extend the schema in meta to accept an array of allowed methods:

schema: [
  {
    type: "object",
    properties: {
      allow: {
        type: "array",
        items: { type: "string" },
        uniqueItems: true,
      }
    },
    additionalProperties: false
  }
]

Then read options like this:

const allowed = (context.options[0] && context.options[0].allow) || ["warn", "error"]

Q: Can I test my rule?
Yes, use eslint.RuleTester. Example in tests/no-console-log.test.js:

const rule = require("../lib/rules/no-console-log");
const { RuleTester } = require("eslint");

const tester = new RuleTester({ parserOptions: { ecmaVersion: 2020 } });

tester.run("no-console-log", rule, {
  valid: ["console.warn('warn')", "console.error('error')"],
  invalid: [
    {
      code: "console.log('debug')",
      errors: [{ messageId: "unexpected" }]

Run tests with:

Best Practices for Custom Rules

✅ Always write tests
✅ Publish your plugin with semantic versioning
✅ Document why the rule exists
✅ Consider upstream contributions if a similar rule might be useful to the community
✅ Consistently pin ESLint versions to avoid breaking upgrades

Conclusion

Custom ESLint rules are a simple but powerful tool to lock in your team’s coding standards, improving consistency and reducing code reviews for style issues.

With the pattern shown above, you can adapt it for any team policy — variable naming, import boundaries, architecture layering, anything.