Написание ESLint плагина: Запрещаем использование console.log

Доброго времени суток, друзья. ESLint — это мощный инструмент для обеспечения качества и единообразия кода в проектах на JavaScript и TypeScript. В дополнение к множеству встроенных правил и существующих плагинов, иногда возникает необходимость в создании собственного плагина ESLint. В этой статье мы рассмотрим, как написать собственный ESLint плагин, который будет запрещать использование console.log в коде. Мы проведем вас через все этапы: от создания проекта до написания и тестирования правила.

Шаг 1: Создание проекта

Для начала создадим новый проект для нашего ESLint плагина:

mkdir eslint-plugin-no-console-log
cd eslint-plugin-no-console-log
npm init -y

После инициализации проекта установим необходимые зависимости:

npm install eslint eslint-plugin eslint-utils

Шаг 2: Структура проекта

Структура нашего проекта будет выглядеть следующим образом:

eslint-plugin-no-console-log/
├── lib/
│   ├── index.js
│   └── rules/
│       └── no-console-log.js
├── tests/
│   └── no-console-log.test.js
├── package.json
└── README.md

— lib/index.js — основной файл плагина.
— lib/rules/no-console-log.js — файл, содержащий наше пользовательское правило.
— tests/no-console-log.test.js — файл с тестами для нашего правила.

Шаг 3: Написание правила

Создадим простое правило, которое будет запрещать использование console.log. Для этого создадим файл lib/rules/no-console-log.js со следующим содержимым:

export default {
  meta: {
    type: 'problem',
    docs: {
      description: 'disallow use of console.log',
      category: 'Best Practices',
      recommended: true,
    },
    schema: [], // не требует опций
    messages: {
      avoidConsoleLog: 'Avoid using console.log().',
    },
  },
  create(context) {
    return {
      MemberExpression(node) {
        if (
          node.object.name === 'console' &&
          node.property.name === 'log'
        ) {
          context.report({
            node,
            messageId: 'avoidConsoleLog',
          });
        }
      },
    };
  },
};

Объяснение кода

— meta: содержит метаданные о правиле. Здесь мы указываем тип правила (problem), описание, категорию и рекомендуемое использование.
— create(context): функция, которая возвращает объект с методами, обрабатывающими различные типы узлов AST. В нашем случае, мы добавляем метод для обработки
— MemberExpression.MemberExpression(node): проверяем, является ли выражение вызовом console.log, и если да, то создаем сообщение об ошибке.

Шаг 4: Регистрация правила

Теперь зарегистрируем наше правило в основном файле плагина. Создадим файл lib/index.js со следующим содержимым:

import noConsoleLog from './rules/no-console-log.js';

export const rules = {
  'no-console-log': noConsoleLog,
};

Шаг 5: Тестирование правила

Создадим файл с тестами для нашего правила: tests/no-console-log.test.js.

import { RuleTester } from 'eslint';
import noConsoleLog from '../lib/rules/no-console-log.js';

const ruleTester = new RuleTester();

ruleTester.run('no-console-log', noConsoleLog, {
  valid: [
    'console.error("error");',
    'console.warn("warning");',
  ],
  invalid: [
    {
      code: 'console.log("hello");',
      errors: [{ messageId: 'avoidConsoleLog' }],
    },
  ],
});

Объяснение кода

— valid: массив примеров кода, которые должны быть допустимыми.
— invalid: массив примеров кода, которые должны вызывать ошибку. В каждом объекте указываем code и ожидаемое сообщение об ошибке.

Шаг 6: Запуск тестов

Для запуска тестов установим Jest:

npm install --save-dev jest

И добавим в package.json следующую строку:

"scripts": {
  "test": "jest"
}

Теперь можем запустить тесты командой:

npm run test

Если все сделано правильно, вы увидите сообщение о успешном прохождении тестов.

Заключение

В этой статье мы рассмотрели процесс создания собственного плагина ESLint с правилом, запрещающим использование console.log. Теперь у вас есть базовые знания, необходимые для разработки своих правил, которые помогут поддерживать качество и стиль вашего кода.

Создание пользовательских плагинов ESLint — это мощный способ адаптации линтинга к специфическим требованиям вашего проекта. Не стесняйтесь экспериментировать и создавать правила, которые улучшат ваш процесс разработки. Happy coding!