Плагин eslint-plugin-unicorn

eslint-plugin-unicorn — один из наиболее насыщенных и прагматичных наборов правил для ESLint, ориентированный на улучшение качества JavaScript и TypeScript-кода за счёт устранения типичных ошибок, антипаттернов и неочевидных проблем производительности. Плагин не дублирует базовые правила ESLint, а расширяет их, предлагая более строгие и современно ориентированные проверки, часто опирающиеся на актуальные возможности языка и практики экосистемы Node.js и браузера.

Плагин построен вокруг идеи «код должен быть не только корректным, но и современным, предсказуемым и лишённым избыточных конструкций». В отличие от многих линтинговых наборов, ориентированных на стиль, eslint-plugin-unicorn делает упор на:

• устранение скрытых багов;
• повышение читаемости без субъективной стилизации;
• использование современных API вместо устаревших подходов;
• предотвращение неэффективных паттернов;
• унификацию решений для частых задач.

Большая часть правил имеет эвристический характер и направлена не на синтаксическую корректность, а на семантические улучшения.

Базовая установка и конфигурация

Плагин подключается как обычная зависимость проекта:

npm install eslint-plugin-unicorn --save-dev

Далее он добавляется в конфигурацию ESLint:

module.exports = {
  plugins: ["unicorn"],
  extends: ["plugin:unicorn/recommended"]
};

Рекомендуемая конфигурация включает набор правил, которые считаются безопасными для большинства проектов. Однако реальная сила плагина раскрывается при тонкой настройке отдельных правил.

Категории правил

Правила можно условно разделить на несколько групп по характеру проверок.

Работа со строками и текстовыми данными

Эта группа направлена на устранение избыточных операций со строками и использование более выразительных методов.

Типичные проверки:

• предпочтение String.prototype.replaceAll вместо регулярных выражений в простых случаях;
• запрет ручной конкатенации там, где возможно использование шаблонных строк;
• предотвращение небезопасных преобразований типов через строковые операции.

Пример антипаттерна:

const message = "Hello " + name + "!";

Рекомендуемая форма:

const message = `Hello ${name}!`;

Работа с массивами и коллекциями

Плагин активно продвигает использование встроенных методов массивов вместо ручных циклов.

Ключевые проверки:

• предпочтение Array.prototype.at вместо индексирования с вычислением длины;
• использование Array.from вместо циклического заполнения;
• запрет избыточных for-циклов, когда возможен map, filter, reduce.

Пример:

const last = arr[arr.length - 1];

Предпочтительно:

const last = arr.at(-1);

Безопасность и предсказуемость кода

Часть правил ориентирована на предотвращение потенциальных ошибок исполнения.

Проверка небезопасных выражений

eslint-plugin-unicorn анализирует конструкции, которые могут приводить к runtime-ошибкам:

• использование undefined и null без явной проверки;
• неявные приведения типов;
• опасные сравнения с == вместо ===.

Пример:

if (value == null) {
  // обработка
}

Такой код часто допускается, но может скрывать неоднозначные состояния. Плагин стимулирует явность:

if (value === null || value === undefined) {
  // обработка
}

Современные API и замены устаревших подходов

Одна из ключевых задач — замена legacy-решений на современные API.

Примеры модернизации

• Object.assign → spread-операторы;
• Array.prototype.indexOf → includes;
• ручные проверки на NaN → Number.isNaN.

Пример:

if (arr.indexOf(item) !== -1) {
  // логика
}

Рекомендуемая форма:

if (arr.includes(item)) {
  // логика
}

Правила именования и структуры кода

Плагин включает проверки, направленные на унификацию структуры:

• запрет «магических» значений;
• требование осмысленных идентификаторов;
• предотвращение избыточных сокращений;
• контроль имен файлов и экспортов.

Пример нарушения:

const d = new Date();

Предпочтительно:

const currentDate = new Date();

Работа с ошибками и исключениями

eslint-plugin-unicorn уделяет внимание корректной обработке ошибок:

• запрет «пустых» catch-блоков;
• требование явной обработки исключений;
• предотвращение игнорирования ошибок Promise.

Пример антипаттерна:

try {
  doSomething();
} catch (e) {}

Рекомендуемая форма:

try {
  doSomething();
} catch (error) {
  logger.error(error);
}

Асинхронный код

В асинхронных сценариях плагин проверяет:

• корректное использование async/await;
• отсутствие лишних then-цепочек;
• предотвращение «fire and forget» без обработки ошибок.

Пример:

fetch(url).then(res => res.json());

Предпочтительно:

const res = await fetch(url);
const data = await res.json();

Производительность и избыточные операции

Некоторые правила направлены на уменьшение лишней вычислительной нагрузки:

• предотвращение повторных вычислений в циклах;
• запрет неэффективных копирований массивов;
• обнаружение лишних преобразований типов.

Пример:

for (let i = 0; i < arr.length; i++) {
  console.log(arr.slice().length);
}

Подобные конструкции считаются крайне неэффективными из-за повторного создания копий данных.

Интеграция с TypeScript

eslint-plugin-unicorn может работать в связке с TypeScript через @typescript-eslint. Однако часть правил требует аккуратной настройки, поскольку:

• типизация уже устраняет некоторые проверки;
• дублирование логики линтинга может привести к конфликтам;
• некоторые правила становятся избыточными.

Практика показывает, что оптимально отключать правила, пересекающиеся с типовой системой, и оставлять семантические проверки.

Конфигурирование отдельных правил

Плагин содержит десятки правил, каждое из которых можно тонко настроить:

rules: {
  "unicorn/prevent-abbreviations": "off",
  "unicorn/filename-case": ["error", { case: "kebabCase" }],
  "unicorn/no-null": "off"
}

Типичные сценарии настройки

• отключение слишком строгих правил именования;
• адаптация под legacy-код;
• включение только правил безопасности;
• ограничение правил форматирования при использовании Prettier.

Частые конфликты с другими инструментами

eslint-plugin-unicorn нередко пересекается с:

• Prettier (форматирование);
• eslint-plugin-import (структура импортов);
• @typescript-eslint (типовые проверки).

На практике важно разделять зоны ответственности:

• Prettier — формат;
• ESLint core — базовая корректность;
• Unicorn — семантика и современность кода.

Практические проблемы внедрения

При внедрении в крупные проекты возникают характерные сложности:

• большое количество предупреждений в legacy-коде;
• необходимость постепенного включения правил;
• сопротивление правилам именования;
• различия в стиле между командами.

Обычно применяется поэтапный rollout:

• сначала recommended;
• затем включение дополнительных правил;
• затем строгие правила именования и структуры.

Поведение в CI/CD

В CI плагин часто используется как gatekeeper качества. Типичная схема:

• ESLint запускается на pull request;
• ошибки unicorn блокируют merge;
• warnings игнорируются или переводятся в soft-fail режим.

Такой подход позволяет постепенно стабилизировать кодовую базу без блокировки разработки.

Влияние на архитектуру кода

При длительном использовании eslint-plugin-unicorn заметно влияет на стиль проектирования:

• уменьшается количество ручных циклов;
• увеличивается использование встроенных API;
• код становится более декларативным;
• снижается количество потенциальных runtime-ошибок;
• структура файлов становится более унифицированной.

Это приводит к тому, что кодовая база начинает постепенно «самоочищаться» от устаревших конструкций и неявных решений.