How to Design Custom ESLint Rules: A Colorful Guide

If you enjoy this story, feel free to like or share it with others who might find it helpful!

---

I decided to design a logo with bold colors for a new brand. As I sat in my studio, surrounded by swatches and creative chaos, I realized that creating a custom ESLint rule for a JavaScript project was quite similar to this colorful endeavor.

I envisioned the logo as the project itself—unique, tailored, and bursting with personality. To craft this distinctive emblem, I needed to set some guidelines, much like I would with an ESLint rule. So, I began by defining the “rules” of my design: I wanted the colors to be bold and harmonious, capturing the essence of the brand.

First, I picked up my brush, equivalent to setting up a new JavaScript file, and started sketching the core shapes—the basic structure of my rule. I knew I wanted my rule to ensure that the project’s code followed a specific pattern, just as I wanted my logo to follow a specific aesthetic.

Next, I mixed the paints, choosing the right shades to bring my vision to life. This was akin to using ESLint’s Abstract Syntax Tree (AST) to analyze the code. I defined the conditions and exceptions, just as I blended colors to find the perfect balance. As I painted, I constantly checked the harmony of the colors, ensuring they worked together seamlessly, much like testing my rule against various code snippets to ensure it functioned correctly.

As the logo took shape, I refined the details—adding shadows here, a splash of color there—fine-tuning my creation. Similarly, I tweaked my ESLint rule, adjusting the logic and adding helpful error messages to guide developers, just as my logo would guide the viewer’s eye.

Finally, I stood back, admiring my work: a bold, beautiful logo that spoke volumes with its colors. In the same way, my custom ESLint rule was now a part of the project’s toolkit, ensuring code quality and consistency with every stroke of the keyboard.

---

First, I started by creating a new directory in my project for ESLint rules, much like setting up a fresh canvas. Inside, I added a new file, no-bold-colors.js, to house my rule. This rule would be like a guideline for developers, ensuring they avoided using inline styles with bold colors directly in JSX.

// no-bold-colors.js
module.exports = {
  meta: {
    type: 'suggestion',
    docs: {
      description: 'disallow inline styles with bold colors',
      category: 'Stylistic Issues',
      recommended: false,
    },
    messages: {
      noBoldColors: 'Avoid using bold colors directly in inline styles.',
    },
    schema: [], // no options
  },
  create(context) {
    return {
      JSXAttribute(node) {
        if (
          node.name.name === 'style' &&
          node.value &&
          node.value.expression &&
          node.value.expression.properties
        ) {
          node.value.expression.properties.forEach((property) => {
            if (
              property.key.name === 'color' &&
              ['red', 'blue', 'green'].includes(property.value.value)
            ) {
              context.report({
                node,
                messageId: 'noBoldColors',
              });
            }
          });
        }
      },
    };
  },
};

In this code, much like mixing the right shades for my logo, I specified a rule that would trigger a warning whenever inline styles with bold colors were detected.

Next, I configured ESLint to recognize my custom rule. I added a new plugin reference in my ESLint configuration file, telling the system where to find my masterpiece.

// .eslintrc.js
module.exports = {
  plugins: ['my-custom-rules'],
  rules: {
    'my-custom-rules/no-bold-colors': 'warn',
  },
};

Just as the logo’s bold colors needed to be in harmony, this setup ensured my rule was part of the project’s stylistic guidelines, maintaining the integrity of the codebase.

As developers worked, much like artists at their easels, the rule provided gentle reminders to steer clear of undesirable patterns. It enforced consistency and quality, just as my logo represented the brand’s vision.

Key Takeaways/Final Thoughts:
Creating a custom ESLint rule is like designing a logo with bold colors: it requires creativity, precision, and careful planning. By setting up a custom rule, you ensure code quality and maintainability, much like how a well-designed logo ensures brand consistency. Don’t be afraid to mix and match, experiment, and refine your rules—each line of code is a stroke towards a more and cohesive project.