ESLint и линтинг правила

ESLint — это инструмент статического анализа кода, который позволяет выявлять потенциальные ошибки, несоответствия стилю кодирования и анти-паттерны в JavaScript и TypeScript проектах. В экосистеме Lit он играет особенно важную роль, так как компоненты Lit активно используют современные возможности языка, шаблоны и реактивные свойства, что требует строгой проверки корректности кода.

Установка и базовая настройка ESLint

Для начала необходимо добавить ESLint в проект:

npm install eslint --save-dev

После установки создается конфигурационный файл .eslintrc.js:

module.exports = {
  root: true,
  env: {
    browser: true,
    es2021: true,
  },
  parserOptions: {
    ecmaVersion: 2021,
    sourceType: 'module',
  },
  extends: [
    'eslint:recommended',
  ],
  rules: {
    // пользовательские правила
  },
};

Ключевые моменты конфигурации:

  • env.browser — указывает, что код рассчитан на выполнение в браузере, и доступны глобальные объекты, такие как window и document.
  • ecmaVersion: 2021 — поддержка последних возможностей ES.
  • extends: ['eslint:recommended'] — набор стандартных рекомендуемых правил ESLint, обеспечивающих базовую безопасность и корректность кода.

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

Lit-компоненты имеют специфическую структуру: реактивные свойства, шаблоны html, слоты и жизненный цикл. Для корректного линтинга полезно подключить плагины:

npm install eslint-plugin-lit --save-dev

Конфигурация с плагином Lit:

module.exports = {
  extends: [
    'eslint:recommended',
    'plugin:lit/recommended'
  ],
  plugins: ['lit'],
  rules: {
    'lit/no-template-arrow': 'error',
    'lit/no-duplicate-template-bindings': 'warn'
  }
};

Особенности правил:

  • lit/no-template-arrow — запрещает использование стрелочных функций внутри шаблонов, чтобы избежать лишних пересозданий функций на каждом рендере.
  • lit/no-duplicate-template-bindings — предупреждает о дублирующихся привязках к одному свойству, что может вызвать неожиданные эффекты при обновлении DOM.

Кастомные правила для проектов на Lit

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

rules: {
  'custom/no-direct-dom-manipulation': 'error',
  'custom/prefer-reactive-properties': 'warn'
}
  • no-direct-dom-manipulation запрещает прямое изменение DOM через document.querySelector или innerHTML, так как Lit управляет DOM самостоятельно.
  • prefer-reactive-properties рекомендует использовать реактивные свойства (@property) вместо обычных полей класса, что улучшает согласованность обновлений компонентов.

Для реализации кастомных правил используется API ESLint с описанием create и слушателей для AST-нод:

module.exports = {
  rules: {
    'no-direct-dom-manipulation': {
      meta: { type: 'problem' },
      create(context) {
        return {
          MemberEx * pression(node) {
            if (
              node.object.name === 'document' &&
              ['querySelector', 'getElementById'].includes(node.property.name)
            ) {
              context.report({
                node,
                message: 'Прямое манипулирование DOM запрещено в Lit компонентах.'
              });
            }
          }
        };
      }
    }
  }
};

Настройка линтинга в редакторах и CI/CD

Для автоматизации проверки кода ESLint интегрируется с редакторами, такими как VSCode, через расширения ESLint. Также удобно запускать линтинг в pipeline CI/CD:

npx eslint src/**/*.js

Добавление в package.json скрипта:

"scripts": {
  "lint": "eslint 'src/**/*.{js,ts}' --fix"
}
  • Опция --fix автоматически исправляет проблемы форматирования и простые нарушения правил.
  • В CI/CD можно настроить обязательное прохождение линтинга перед сборкой, что предотвращает попадание неконсистентного кода в продакшен.

Лучшие практики линтинга для Lit

  1. Использование реактивных свойств: все состояния компонентов должны быть реактивными через @property или @state.
  2. Избегать прямого доступа к DOM: любые манипуляции через querySelector или innerHTML заменяются привязками и шаблонами Lit.
  3. Минимизация стрелочных функций в шаблонах: стрелочные функции в html создают новые объекты на каждом рендере.
  4. Строгие правила именования: свойства и методы компонентов должны быть информативными и уникальными для избежания конфликтов.
  5. Регулярный запуск линтера: ESLint должен быть частью ежедневного workflow, а не отложенной проверки перед релизом.

ESLint в проектах на Lit не только обеспечивает чистоту и читаемость кода, но и помогает предотвращать баги, связанные с особенностями реактивного рендеринга и шаблонов. Правильная конфигурация плагинов и кастомных правил становится фундаментом масштабируемых и стабильных приложений.

Оглавление