Форум программистов, компьютерный форум, киберфорум
run.dev
Войти
Регистрация
Восстановить пароль

Анализ и линтинг кода JavaScript: ESLint, Prettier и JSHint

Запись от run.dev размещена 26.04.2025 в 20:19
Показов 4508 Комментарии 0

Нажмите на изображение для увеличения
Название: e7227c3d-c904-4237-a471-6dea534aa3b5.jpg
Просмотров: 82
Размер:	213.7 Кб
ID:	10675
JavaScript прошёл долгий путь от простого языка для анимации веб-страниц до основы современной веб-разработки. С ростом сложности приложений, увеличением кодовых баз и масштабированием команд разработчиков возникла острая необходимость в инструментах, способных обеспечить контроль качества кода. Статический анализ кода и линтинг стали неотъемлемыми элементами зрелого процесса разработки на JavaScript. В отличие от компилируемых языков, где часть ошибок отлавливается на этапе компиляции, JavaScript как интерпретируемый язык не имеет этого защитного слоя. Ошибки вкоде могут проявиться только во время выполнения, причём возможно в самый неподходящий момент — когда приложением уже пользуются реальные пользователи. Статический анализ кода частично компенсирует этот недостаток, проверяя код до его запуска.

Анализ кода в JavaScript выполняет несколько ключевых функций:
1. Поиск потенциальных ошибок и уязвимостей. Инструменты анализа способны обнаружить неиспользуемые переменные, недоступный код, неправильное использование операторов сравнения, утечки памяти и другие проблемы, которые могут привести к багам.
2. Поддержание единого стиля кода. В командной разработке критически важно следовать общим соглашениям по стилю. Когда над проектом работают десятки разработчиков, без автоматического контроля стиля код быстро превращается в лоскутное одеяло из несовместимых подходов к форматированию.
3. Обеспечение соответствия лучшим практикам. Многие паттерны в JavaScript могут работать, но считаются антипаттернами из-за неочевидных проблем, которые они создают. Инструменты анализа помогают придерживаться рекомендованных практик.
4. Упрощение рефакторинга и поддержки. Чистый, последовательный код проще модифицировать и поддерживать. Автоматизация проверок освобаждает время разработчиков для решения более сложных задач.

Примечательно что JavaScript, изначально созданный как простой язык сценариев, сегодня используется для разработки сложных систем с миллионами строк кода. Исследование, проведённое GitHub в 2022 году, показало, что проекты, активно применяющие инструменты анализа кода, имеют на 30% меньше критических дефектов при равной функциональности.

Когда мы говорим о современной JavaScript-разработке, нельзя не затронуть её особености — множество диалектов (ES5, ES6+, TypeScript), асинхронное программирование, множество фреймворков и библиотек. Каждый из этих аспектов вносит свои нюансы в процесс анализа кода.

JavaScript
1
2
3
4
5
6
7
8
// Код без линтинга - потенциальные проблемы
function getUserData(id)
{
    var userData = fetchData(id);  // Устаревший var
    if (userData.status == "active")  // Нестрогое сравнение
    userData.lastLogin = new Date();  // Отступы не соблюдены
    return userData
}  // Отсутствие точки с запятой
JavaScript
1
2
3
4
5
6
7
8
// Тот же код после линтинга
function getUserData(id) {
    const userData = fetchData(id);
    if (userData.status === "active") {
        userData.lastLogin = new Date();
    }
    return userData;
}
Внедрение инструментов анализа в рабочий процесс имеет и экономическое обоснование. По исследованиям Microsoft и Google, до 85% затрат на программное обспечение приходится на поддержку и исправление ошибок. Раннее выявление проблем эначительно снижает эти затраты.

В JavaScript-экосистеме сформировался набор ключевых инструментов анализа кода:
ESLint — наиболее гибкий и настраиваемый инструмент, позволяющий создавать собственные правила и подключать плагины для различных фреймворков,
Prettier — фокусируется исключительно на форматировании кода, убирая споры о стиле из рабочего процесса,
JSHint — один из первых популярных линтеров, всё ещё используемый во многих проектах.

Интересен переход от "карательного" к "помогающему" подходу в анализе кода. Современные инструменты не просто указывают на проблемы, но и предлагают автоматические исправления. Это меняет восприятие линтеров — от инструментов надзора к помощникам разработчика. Интеграция анализаторов кода в редакторы и IDE позволяет получать обратную связь в реальном времени, что ускоряет обучение и повышает качество кода. А встраивание в CI/CD-пайплайны гарантирует, что низкокачественный код не попадёт в продакшн.

Историческое развитие инструментов линтинга



История инструментов линтинга JavaScript начинается задолго до современных ESLint и Prettier. Сам термин "линтинг" происходит от программы Lint для языка C, созданной Стивеном Джонсоном в 1978 году. Название отсылает к процессу удаления ворсинок (lint) с одежды — аналогично инструмент "вычищал" мелкие ошибки из кода. Эта метафора закрепилась в программировании и перешла в JavaScript-экосистему. Первым значимым линтером для JavaScript стал JSLint, созданный Дугласом Крокфордом в 2002 году. Крокфорд, известный как автор книги "JavaScript: Хорошие части" и формата JSON, создал JSLint из-за разочарования в качестве JavaScript-кода того времени. JSLint был категоричным инструментом с жёсткими правилами, отражающими личные убеждения Крокфорда о "правильном JavaScript". Философия инструмента выражалась его девизом: "JSLint причинит вам боль и это хорошо".

JavaScript
1
2
3
4
5
6
7
// Код, который не пройдёт проверку JSLint
function example() {
    return              // JSLint выдаст ошибку из-за переноса строки
    {
        value: true     // (автоматическая вставка точки с запятой)
    };
}
Жёсткость JSLint вызывала недовольство сообщества. В 2011 году Антон Ковалёв форкнул проект и создал JSHint — более гибкий линтер, позволяющий настраивать правила под нужды проекта. JSHint быстро набрал популярность, поскольку давал разработчикам контроль над процессом анализа кода. Следующим революционным шагом стало появление ESLint, созданного Николасом Закасом в 2013 году. ESLint был спроектирован с нуля как полностью настраиваемый и расширяемый инструмент. Ключевой инновацией стала плагинная архитектура, позволяющая разработчикам создавать собственные правила, а также концепция парсеров, дающая возможность анализировать код на различных диалектах JavaScript и даже JSX.

Закас вспоминал: "Я создал ESLint, потому что был недоволен отсутствием расширяемости в существующих инструментах. Мне хотелось иметь возможность создавать собственные правила для конкретных случаев использования".

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

JavaScript
1
2
3
4
5
6
7
8
9
10
11
// До ESLint с автофиксом
var x = 5;
if(x==5){
console.log("Equal");
}
 
// После автофикса
const x = 5;
if (x === 5) {
    console.log("Equal");
}
В 2017 году Джеймс Лонг представил Prettier — инструмент, фокусирующийся исключительно на форматировании кода. В отличие от предшественников, Prettier принимал минимальное количество настроек, продвигая идею "стандарта не имеет значения, важна только согласованность". Этот подход резонировал со многими командами, уставшими от бесконечных споров о стиле кода. Параллельно развивались специализированные инструменты для конкретных фреймворков. Например, TSLint создавался специально для TypeScript, хотя позже был вытеснен ESLint с поддержкой TypeScript. Похожая судьба постигла StandardJS, предлагавший "нулевую конфигурацию", но уступивший в гибкости ESLint с пресетами.

Современный период характеризуется консолидацией вокруг ESLint и Prettier, которые часто используются вместе. ESLint отвечает за семантический анализ кода, в то время как Prettier берёт на себя форматирование. Это разделение обязаностей оказалось продуктивным и прагматичным. Эволюция линтеров отражает более глубокие изменения в культуре разработки JavaScript — от хаотичного подхода ранних дней к структурированным методологиям современности, где качеству кода и согасованности придаётся первостепенное значение.

Создание проекта на ts.eslint.prettier Ошибка
Добрый день! Ни разу не был знаком с typescript export const LoginPage = () => { return ( ...

JSHint для Sublime Text 2
Приветствую всех. Не получается установить JSHint для Sublime Text 2, все делаю по инструкции......

Не хочет работать jshint в vim'e
Привет! Перепробывал кучу плагинов для vim: jshint.vim, jshint2.vim и т.д. В итоге во всех...

Стоит ли использовать ESLint в vue/cli приложении?
Всем привет! Имея опыт работы с Laravel 5 / vuejs 2 хочу освоить vue/cli и сразу столкнулся что...


ESLint: гибкий инструмент статического анализа



ESLint занимает особое место в экосистеме JavaScript благодаря своей непревзойдённой гибкости и расширяемости. Созданный в 2013 году, он быстро стал стандартом де-факто для статического анализа кода, вытеснив предшественников благодаря модульной архитектуре и возможности тонкой настройки.

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

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



Начать работу с ESLint проще простого:

Bash
1
2
3
4
5
# Глобальная установка
npm install -g eslint
 
# Локальная установка (рекомендуется)
npm install --save-dev eslint
После установки необходимо инициализировать конфигурацию с помощью команды:

Bash
1
npx eslint --init
Эта команда запустит интерактивный мастер настройки, который задаст несколько вопросов о вашем проекте и создаст файл .eslintrc.js с базовыми настройками. Альтернативно, вы можете создать такой файл вручную:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
module.exports = {
  env: {
    browser: true,
    es2021: true,
    node: true
  },
  extends: 'eslint:recommended',
  parserOptions: {
    ecmaVersion: 2021,
    sourceType: 'module'
  },
  rules: {
    'indent': ['error', 2],
    'linebreak-style': ['error', 'unix'],
    'quotes': ['error', 'single'],
    'semi': ['error', 'always']
  }
};

Уровни серьёзности правил



ESLint использует три уровня серьёзности для правил:

"off" или 0 — правило отключено,
"warn" или 1 — нарушение правила вызывает предупреждение,
"error" или 2 — нарушение правила вызывает ошибку.

Вот как это выглядит в конфигурации:

JavaScript
1
2
3
4
5
6
7
{
  "rules": {
    "no-console": "warn",      // Предупреждение при использовании console
    "no-unused-vars": "error", // Ошибка при неиспользуемых переменных
    "eqeqeq": "off"            // Отключение требования строгого равенства
  }
}

Расширение базовых конфигураций



Одна из сильных сторон ESLint — возможность наследования и комбинирования готовых наборов правил. Это экономит время при настройке и обеспечивает соответствие общепринятым стандартам. Популярные наборы включают:

eslint:recommended — базовый набор рекомендованных правил,
airbnb — строгий стиль от Airbnb, требует установки eslint-config-airbnb,
standard — JavaScript Standard Style, менее строгий, чем Airbnb,
google — стиль, используемый в Google.

Пример комбинирования наборов правил:

JavaScript
1
2
3
4
5
6
7
{
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended"
  ]
}

Интеграция с редакторами и IDE



Реальная ценность ESLint раскрывается при его интеграции с редактором кода. Большинство современных IDE предлагают встроенную поддержку или плагины для ESLint:
VSCode: расширение ESLint показывает ошибки прямо в редакторе и может автоматически исправлять некоторые из них при сохранении файла,
WebStorm: встроенная поддержка ESLint с возможностью фикса проблем,
Sublime Text: доступен через пакет SublimeLinter-eslint.

Продвинутые настройки



ESLint позволяет задавать разные правила для разных файлов с помощью overrides:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
{
  "rules": { /* общие правила */ },
  "overrides": [
    {
      "files": ["*.test.js", "*.spec.js"],
      "rules": {
        "no-unused-expressions": "off" // Отключаем для тестовых файлов
      }
    }
  ]
}
Также возможно игнорировать файлы и директории через .eslintignore:

JavaScript
1
2
3
4
node_modules/
dist/
build/
coverage/

Автоисправление ошибок



Одно из ключевых преимуществ ESLint — возможность автоматического исправления некоторых проблем. Запустите ESLint с флагом --fix:

Bash
1
npx eslint src/ --fix
Это исправит все автоматически исправимые проблемы, такие как форматирование, отступы, замена двойных кавычек на одинарные и т.д.

Интеграция с системами сборки



Включение ESLint в процесс сборки помогает предотвратить попадание проблемного кода в репозиторий:

Webpack:
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
// webpack.config.js
module.exports = {
  // ...
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: ['babel-loader', 'eslint-loader']
      }
    ]
  }
}
npm scripts:
JavaScript
1
2
3
4
5
6
7
8
on
{
  "scripts": {
    "lint": "eslint src/",
    "lint:fix": "eslint src/ --fix",
    "precommit": "npm run lint"
  }
}

Пример реального применения



Представьте, что вы работаете над проектом с асинхронными операциями. ESLint может помочь предотвратить распространённые ошибки:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
// Без ESLint
function fetchData() {
  return new Promise((resolve, reject) => {
    // Забыли вернуть результат из колбэка
    callApi().then(data => {
      processData(data);
    });
  });
}
 
// ESLint предупредит об отсутствии return в колбэке
Правило no-return-await обнаружит неоптимальные конструкции:

JavaScript
1
2
3
4
5
6
7
8
9
// Неоптимально
async function getData() {
  return await fetchData(); // Избыточное await
}
 
// Оптимально
async function getData() {
  return fetchData();
}
ESLint становится не просто инструментом проверки стиля, но и наставником, помогающим улучшать код и избегать подводных камней JavaScript. Возможность кастомизации делает его незаменимым как для индивидуальных разработчиков, так и для крупных команд с устоявшимися стандартами кодирования.

Работа с различными синтаксисами и диалектами JavaScript



Одной из сильнейших сторон ESLint является его способность работать с разными диалектами JavaScript и расширениями синтаксиса. Это особенно важно в современной веб-разработке, где TypeScript, JSX и другие суперсеты JavaScript стали обыденностью. Для работы с TypeScript вам понадобится парсер @typescript-eslint/parser и соответствующий набор правил:

Bash
1
npm install --save-dev @typescript-eslint/parser @typescript-eslint/eslint-plugin
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// .eslintrc.js для TypeScript-проекта
module.exports = {
  parser: '@typescript-eslint/parser',
  plugins: ['@typescript-eslint'],
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended'
  ],
  parserOptions: {
    ecmaVersion: 2021,
    sourceType: 'module',
    project: './tsconfig.json' // Путь к файлу tsconfig
  }
};
Аналогичная история с React и JSX:

Bash
1
npm install --save-dev eslint-plugin-react eslint-plugin-jsx-a11y
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// .eslintrc.js для React-проекта
module.exports = {
  extends: [
    'eslint:recommended',
    'plugin:react/recommended',
    'plugin:jsx-a11y/recommended'
  ],
  plugins: ['react', 'jsx-a11y'],
  parserOptions: {
    ecmaFeatures: {
      jsx: true
    }
  },
  settings: {
    react: {
      version: 'detect' // Автоматически определять версию React
    }
  }
};

Интеграция с системами CI/CD



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

GitHub Actions:
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# .github/workflows/lint.yml
name: Lint
 
on: [push, pull_request]
 
jobs:
  eslint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '16'
      - run: npm ci
      - run: npm run lint
GitLab CI:
YAML
1
2
3
4
5
6
# .gitlab-ci.yml
lint:
  image: node:16
  script:
    - npm ci
    - npm run lint
Продвинутые пайплайны могут включать фазу автоматического исправления ошибок и создания отдельного pull request с фиксами:

YAML
1
2
3
4
5
6
7
8
9
10
11
12
lint-fix:
  if: github.event_name == 'pull_request'
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{ github.head_ref }}
    - run: npm ci
    - run: npm run lint:fix
    - uses: stefanzweifel/git-auto-commit-action@v4
      with:
        commit_message: "style: automatic ESLint fixes"

Производительность и кэширование



При работе с крупными проектами производительность ESLint может стать узким местом. К счастью, существуют способы оптимизации:

1. Использование кэширования:
Bash
1
npx eslint src/ --cache
Это создаст файл .eslintcache, который значительно ускорит повторные проверки.

2. Параллельное выполнение:
Bash
1
2
npm install --save-dev eslint-plugin-only-warn
npx eslint-parallel src/
3. Выборочная проверка измененных файлов:
Bash
1
2
# Проверять только файлы, измененные с момента последнего коммита
git diff --name-only HEAD | grep -E '\.(js|jsx|ts|tsx)$' | xargs eslint

Внедрение ESLint в существующий проект



Добавление ESLint в зрелый проект требует продуманной стратегии, чтобы не парализовать разработку сотнями ошибок. Вот поэтапный подход:

1. Начните с режима предупреждений:
JavaScript
1
2
3
4
5
6
7
8
9
// .eslintrc.js
module.exports = {
  rules: {
    // Все правила только предупреждают, но не блокируют сборку
    'indent': ['warn', 2],
    'no-unused-vars': 'warn'
    // ...другие правила
  }
};
2. Внедряйте правила постепенно:
JavaScript
1
2
3
4
5
6
7
8
9
10
11
// Неделя 1: только критичные правила
{
  "rules": {
    "no-unused-vars": "error",
    "no-undef": "error"
    // Остальные пока отключены
  }
}
 
// Неделя 2: добавляем правила форматирования
// И так далее
3. Используйте инструменты автоматизации:
Bash
1
2
3
4
5
# Исправление всех автофиксируемых проблем
npx eslint --fix src/
 
# Для сложных случаев можно использовать jscodeshift
npx jscodeshift -t transform-rule.js src/
Один из наиболее эффективных подходов — правило "бойскаута": каждый раз, когда вы изменяете файл, приводите его в соответствие со стандартами ESLint. Это обеспечивает постепенное улучшение качества кода без необходимости останавливать разработку для масштабного рефакторинга.

ESLint и командная работа



ESLint особенно ценен в контексте командной разработки. Он служит не только инструментом обеспечения качества, но и средством обучения и передачи знаний между разработчиками. Интересный подход — добавлять комментарии к правилам в конфигурации:

JavaScript
1
2
3
4
5
6
7
8
9
{
  "rules": {
    // Предотвращает утечки памяти в замыканиях
    "no-unused-vars": "error",
    
    // Помогает избежать проблем с асинхронным кодом
    "no-async-promise-executor": "error"
  }
}
Для крупных команд полезно создать документацию по принятым стандартам кода:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
/**
 * @fileoverview Пример документированного правила ESLint
 * @author Ваша Команда
 *
 * Это правило предотвращает распространённую ошибку при работе с async/await,
 * когда разработчики забывают обрабатывать ошибки, что может привести к "проглатыванию"
 * исключений и трудноотлавливаемым багам.
 *
 * Пример НЕПРАВИЛЬНОГО кода:
 *
 * async function fetchData() {
 *   const data = await api.getData(); // Если здесь будет ошибка, она будет проигнорирована
 *   return process(data);
 * }
 *
 * Пример ПРАВИЛЬНОГО кода:
 *
 * async function fetchData() {
 *   try {
 *     const data = await api.getData();
 *     return process(data);
 *   } catch (error) {
 *     logger.error('Ошибка получения данных', error);
 *     throw error; // Переброс ошибки или другая обработка
 *   }
 * }
 */
Подобные комментарии могут служить учебным материалом для новых членов команды, особенно если они не имеют большого опыта работы с JavaScript.

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

Плагинная архитектура ESLint и создание собственных правил



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

Как устроены плагины ESLint



Плагин ESLint — это обычный npm-пакет, экспортирующий объект с правилами и, опционально, конфигурациями. Такая простая структура делает создание плагинов доступным для любого JavaScript-разработчика.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
module.exports = {
  rules: {
    "my-custom-rule": {
      create: function(context) {
        // Логика правила
        return {
          // Обработчики AST-узлов
        };
      }
    }
  }
};
Плагины придерживаются соглашения об именовании: eslint-plugin-имя. После установки такой плагин можно подключить в конфигурации:

JavaScript
1
2
3
4
5
6
7
{
  "plugins": ["react", "my-plugin"],
  "rules": {
    "react/jsx-uses-vars": "error",
    "my-plugin/my-custom-rule": "warn"
  }
}

Анатомия правила ESLint



Каждое правило в ESLint — это модуль, экспортирующий единственную функцию create, которая получает объект контекста. Эта функция возвращает объект с методами-обработчиками для различных узлов абстрактного синтаксического дерева (AST).

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
module.exports = {
  create: function(context) {
    return {
      // Вызывается для каждого объявления функции
      FunctionDeclaration: function(node) {
        // Проверяем условия и сообщаем об ошибках
        if (hasIssue(node)) {
          context.report({
            node: node,
            message: "Описание проблемы",
            fix: function(fixer) {
              // Опциональный автофикс
              return fixer.replaceText(node, fixedCode);
            }
          });
        }
      }
    };
  }
};
Когда ESLint анализирует код, он преобразует его в AST и затем обходит это дерево, вызывая соответствующие обработчики для каждого узла. Такая архитектура делает возможным создание правил практически для любого аспекта кода.

Создание собственного правила



Допустим, мы хотим создать правило, запрещающее использование переменных с именами короче 3 символов (за исключением i, j, k для циклов). Вот как это можно реализовать:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// no-short-vars.js
module.exports = {
  meta: {
    type: "suggestion",
    docs: {
      description: "Запрещает переменные с коротким именем",
      category: "Best Practices",
      recommended: false
    },
    fixable: null, // или "code" если есть автофикс
    schema: [] // опции правила
  },
  create: function(context) {
    // Список разрешённых коротких имён
    const exceptions = ["i", "j", "k", "id", "fs", "db"];
    
    return {
      VariableDeclarator: function(node) {
        const name = node.id.name;
        
        if (name.length < 3 && !exceptions.includes(name)) {
          context.report({
            node: node.id,
            message: "Имя переменной '{{name}}' слишком короткое. Используйте минимум 3 символа.",
            data: {
              name: name
            }
          });
        }
      }
    };
  }
};
Чтобы использовать это правило, нужно создать директорию eslint-plugin-my-rules и поместить туда файл index.js:

JavaScript
1
2
3
4
5
module.exports = {
  rules: {
    "no-short-vars": require("./no-short-vars")
  }
};
Затем установить этот плагин локально и подключить в конфигурации:

JavaScript
1
2
3
4
5
6
{
  "plugins": ["my-rules"],
  "rules": {
    "my-rules/no-short-vars": "error"
  }
}

Автоматическое исправление ошибок



Реальная мощь правил ESLint раскрывается, когда они могут не только обнаруживать проблемы, но и автоматически их исправлять. Для этого в методе report используется опция fix:

JavaScript
1
2
3
4
5
6
7
context.report({
  node: node,
  message: "Используйте строгое равенство (===) вместо (==)",
  fix: function(fixer) {
    return fixer.replaceText(node.operator, "===");
  }
});
Объект fixer предоставляет методы для различных видов исправлений:

replaceText(node, text) — замена текста узла,
insertTextAfter(node, text) — вставка текста после узла,
insertTextBefore(node, text) — вставка текста перед узлом,
remove(node) — удаление узла,
replaceTextRange([start, end], text) — замена диапазона текста.

Вот пример правила, которое автоматически добавляет фигурные скобки к однострочным блокам if:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// always-braces.js
module.exports = {
  create: function(context) {
    return {
      IfStatement(node) {
        if (node.consequent && node.consequent.type !== "BlockStatement") {
          context.report({
            node: node.consequent,
            message: "Блоки if должны использовать фигурные скобки",
            fix: function(fixer) {
              const sourceCode = context.getSourceCode();
              const consequentText = sourceCode.getText(node.consequent);
              return fixer.replaceText(node.consequent, [INLINE]{ ${consequentText} }[/INLINE]);
            }
          });
        }
      }
    };
  }
};

Работа с AST-деревом



Для создания эффективных правил необходимо понимать структуру AST. Самый быстрый способ ознакомиться с ней — использовать онлайн-инструменты, такие как AST Explorer, где можно увидеть, как JavaScript-код преобразуется в AST.
Вот типичная структура узлов для некоторых конструкций:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// Объявление переменной: let x = 5;
{
  type: "VariableDeclaration",
  declarations: [
    {
      type: "VariableDeclarator",
      id: {
        type: "Identifier",
        name: "x"
      },
      init: {
        type: "Literal",
        value: 5
      }
    }
  ],
  kind: "let"
}
 
// Вызов функции: console.log("Hello");
{
  type: "ExpressionStatement",
  expression: {
    type: "CallExpression",
    callee: {
      type: "MemberExpression",
      object: {
        type: "Identifier",
        name: "console"
      },
      property: {
        type: "Identifier",
        name: "log"
      }
    },
    arguments: [
      {
        type: "Literal",
        value: "Hello"
      }
    ]
  }
}

Шаринг и публикация плагинов



Если ваш плагин может быть полезен другим, его можно опубликовать в npm. Для этого нужно убедиться, что:
1. Имя пакета следует соглашению eslint-plugin-имя.
2. В package.json включены ключевые слова "eslint" и "eslint-plugin".
3. Документация описывает все правила и их настройки.
Пример package.json для плагина:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
on
{
  "name": "eslint-plugin-my-rules",
  "version": "1.0.0",
  "description": "Custom ESLint rules for my team",
  "main": "index.js",
  "keywords": ["eslint", "eslint-plugin", "javascript"],
  "peerDependencies": {
    "eslint": ">=6.0.0"
  }
}
Создание собственных правил ESLint открывает новые возможности для контроля качества кода. Вы можете автоматизировать проверку специфичных для вашего проекта соглашений, предотвращать типичные ошибки и даже обучать новых разработчиков принятым в команде стандартам. Плагинная архитектура ESLint — это именно то, что делает его не просто линтером, а мощной платформой для развития культуры качественного кода.

Использование пресетов ESLint для типовых проектов



Ручная настройка ESLint с нуля — увлекательное, но трудоёмкое занятие. К счастью, сообщество уже создало множество готовых конфигураций (пресетов) для типовых проектов, которые можно использовать как отправную точку. Это позволяет быстро настроить линтер в соответствии с общепринятыми практиками для конкретной технологии или фреймворка.

Что такое пресеты



Пресет (preset) в контексте ESLint — это готовый набор правил и настроек, опубликованный как npm-пакет. Пресеты обычно создаются компаниями, сообществами или командами разработчиков фреймворков, чтобы стандартизировать подход к написанию кода. Использование пресетов имеет несколько преимуществ:
  1. Экономия времени на настройке.
  2. Соответствие общепринятым стандартам в экосистеме.
  3. Меньше споров в команде о стиле кода.
  4. Применение лучших практик, проверенных сообществом.

Популярные пресеты



eslint-config-airbnb



Один из самых популярных пресетов, разработанный компанией Airbnb. Содержит строгий набор правил, основанный на их внутреннем руководстве по стилю JavaScript.

Bash
1
2
# Установка
npx install-peerdeps --dev eslint-config-airbnb
JavaScript
1
2
3
4
5
6
7
8
// .eslintrc.js
module.exports = {
  extends: ['airbnb'],
  rules: {
    // Переопределение правил при необходимости
    'react/jsx-filename-extension': [1, { extensions: ['.js', '.jsx'] }]
  }
};
Airbnb также предлагает облегчённую версию без React-специфичных правил: eslint-config-airbnb-base.

eslint-config-standard



JavaScript Standard Style — менее строгий набор правил, отличающийся некоторыми неортодоксальными решениями, например, отказом от точек с запятой.

Bash
1
npm install --save-dev eslint-config-standard eslint-plugin-promise eslint-plugin-import eslint-plugin-n
JavaScript
1
2
3
4
// .eslintrc.js
module.exports = {
  extends: ['standard']
};

@typescript-eslint/eslint-plugin



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

Bash
1
npm install --save-dev @typescript-eslint/eslint-plugin @typescript-eslint/parser
JavaScript
1
2
3
4
5
6
7
8
9
// .eslintrc.js
module.exports = {
  parser: '@typescript-eslint/parser',
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended'
  ],
  plugins: ['@typescript-eslint']
};

eslint-plugin-react



Набор правил для React-разработки, проверяющий специфичные антипаттерны и соблюдение лучших практик.

Bash
1
npm install --save-dev eslint-plugin-react
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
// .eslintrc.js
module.exports = {
  extends: [
    'eslint:recommended',
    'plugin:react/recommended'
  ],
  plugins: ['react'],
  settings: {
    react: {
      version: 'detect' // Автоматическое определение версии React
    }
  }
};

eslint-plugin-vue



Официальный пресет для Vue.js, разработанный командой фреймворка.

Bash
1
npm install --save-dev eslint-plugin-vue
JavaScript
1
2
3
4
5
6
7
// .eslintrc.js
module.exports = {
  extends: [
    'plugin:vue/recommended'
  ],
  parser: 'vue-eslint-parser'
};

Комбинирование пресетов



Одно из преимуществ ESLint — возможность комбинировать различные пресеты. Это особенно полезно для проектов, использующих несколько технологий.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// React + TypeScript + Airbnb
module.exports = {
  parser: '@typescript-eslint/parser',
  extends: [
    'airbnb',
    'airbnb/hooks',
    'plugin:@typescript-eslint/recommended',
    'plugin:react/recommended'
  ],
  plugins: [
    'react',
    '@typescript-eslint'
  ],
  settings: {
    react: {
      version: 'detect'
    }
  },
  rules: {
    // Разрешаем .tsx расширения для React-компонентов
    'react/jsx-filename-extension': [1, { extensions: ['.tsx', '.jsx'] }],
    // Отключаем правило импорта расширений для TypeScript
    'import/extensions': ['error', 'ignorePackages', {
      js: 'never',
      jsx: 'never',
      ts: 'never',
      tsx: 'never'
    }]
  }
};
При комбинировании пресетов важно помнить о порядке в массиве extends. Последующие конфигурации перезаписывают правила предыдущих, поэтому специфические пресеты лучше размещать в конце списка.

Создание собственного пресета



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

JavaScript
1
2
3
4
5
6
7
8
9
10
11
// eslint-config-mycompany/index.js
module.exports = {
  extends: ['airbnb', 'plugin:react/recommended'],
  rules: {
    // Наши корпоративные стандарты
    'indent': ['error', 2],
    'quotes': ['error', 'single'],
    'react/prop-types': 'off',
    'import/prefer-default-export': 'off'
  }
};
Опубликуйте этот пакет в npm (приватно или публично) и используйте во всех проектах:

JavaScript
1
2
3
4
// В любом проекте
module.exports = {
  extends: ['mycompany']
};

Рабочий процесс с пресетами



Выбор и настройка пресетов обычно происходит в начале проекта. Вот рекомендуемый процесс:
1. Выбор базового пресета в зависимости от типа проекта (Airbnb, Standard, Google и т.д.).
2. Добавление технологически-специфичных пресетов (React, Vue, TypeScript).
3. Тестирование на существующем коде и анализ количества предупреждений/ошибок.
4. Постепенное ослабление или усиление правил в зависимости от потребностей команды.
Не стоит бояться отключать или изменять правила из пресетов, если они не соответствуют вашему стилю или специфике проекта. Главная цель — не слепое следование чужим стандартам, а улучшение качества и поддерживаемости вашего кода.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
// Пример постепенной адаптации
module.exports = {
  extends: ['airbnb'],
  rules: {
    // На начальном этапе включаем как предупреждения
    'no-console': 'warn',
    'react/jsx-filename-extension': 'warn',
    
    // Со временем можно ужесточить до errors
    // 'no-console': 'error',
  }
};

Интеграция с редакторами



Большинство редакторов автоматически распознают конфигурацию ESLint и пресеты. Для VS Code достаточно установить расширение ESLint, и оно будет подсвечивать ошибки согласно выбранному пресету прямо в редакторе.

JavaScript
1
2
3
4
5
6
7
8
on
// .vscode/settings.json
{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "eslint.validate": ["javascript", "javascriptreact", "typescript", "typescriptreact", "vue"]
}
Использование пресетов — это не только экономия времени, но и способ обучения. Изучая правила, включенные в популярные пресеты, разработчики знакомятся с лучшими практиками и типичными ошибками в экосистеме JavaScript. Это делает пресеты неоценимым инструментом как для новичков, так и для опытных разработчиков, стремящихся поддерживать высокий уровень качества кода.

Prettier: форматирование без компромиссов



В отличие от ESLint, который фокусируется на поиске ошибок и соблюдении правил кодирования, Prettier — это инструмент, заточенный исключительно под форматирование кода. Его главная миссия звучит просто: «Забудьте о спорах вокруг стиля кода». И действительно, сколько времени разработчики тратят на обсуждение отступов, переносов строк и расстановки фигурных скобок? Созданный Джеймсом Лонгом в 2017 году, Prettier быстро завоевал популярность благодаря своему радикальному подходу: форматирование должно быть полностью автоматическим, предсказуемым и с минимальными возможностями настройки.

Философия Prettier



Философия Prettier основана на нескольких ключевых принципах:

1. Категоричность вместо гибкости. В отличие от большинства инструментов, Prettier намеренно ограничивает количество настроек. Лонг утверждал, что большинство споров о стиле кода субъективны, и наилучшее решение — это консистентность, а не соответствие личным предпочтениям.
2. Форматирование как перепечатка. Prettier не просто вносит небольшие изменения в существующий код — он полностью разбирает AST и печатает код заново с нуля по своим правилам. Это гарантирует единообразие даже для сильно различающихся стилей исходного кода.
3. Интеграция в рабочий процесс. Prettier спроектирован для запуска на каждом сохранении файла или при коммите, обеспечивая постоянное соответствие кода единому стилю без ручного вмешательства.

Установка и базовое использование



Установить Prettier так же просто, как и любой другой npm-пакет:

Bash
1
2
3
4
5
# Локальная установка (рекомендуется)
npm install --save-dev prettier
 
# Глобальная установка
npm install -g prettier
После установки вы можете форматировать файлы из командной строки:

Bash
1
2
3
4
5
# Форматирование одного файла
npx prettier --write src/index.js
 
# Форматирование всех файлов JavaScript и CSS в директории
npx prettier --write "src/**/*.{js,jsx,ts,tsx,css,scss}"
Флаг --write указывает Prettier перезаписать файлы отформатированной версией. Без этого флага отформатированный код будет выведен в консоль, что полезно для проверки результатов.

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



Хотя Prettier намеренно ограничивает возможности настройки, некоторые опции всё же доступны. Конфигурацию можно задать в файле .prettierrc в корне проекта:

JSON
1
2
3
4
5
6
7
8
9
10
{
  "printWidth": 80,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": false,
  "trailingComma": "es5",
  "bracketSpacing": true,
  "arrowParens": "always"
}
Вот некоторые из наиболее используемых опций:
printWidth: максимальная длина строки (по умолчанию 80),
tabWidth: количество пробелов в табуляции (по умолчанию 2),
useTabs: использовать табуляцию вместо пробелов (по умолчанию false),
semi: добавлять точки с запятой (по умолчанию true),
singleQuote: использовать одинарные кавычки (по умолчанию false),
trailingComma: стратегия добавления завершающих запятых (по умолчанию "es5").

Преимущества использования Prettier



Внедрение Prettier в рабочий процесс даёт несколько существенных преимуществ:
1. Экономия времени. Разработчики больше не тратят время на ручное форматирование кода и бесконечные дискуссии о стиле.
2. Улучшение читаемости. Однородно отформатированный код проще читать и понимать.
3. Упрощение ревью кода. Без отвлечения на вопросы форматирования ревьюеры могут сконцентрироваться на логике и реализации.
4. Уменьшение конфликтов при слиянии. Поскольку весь код форматируется одинаково, количество конфликтов, связанных с пробелами и переносами строк, существенно снижается.

Поддерживаемые языки и технологии



Первоначально Prettier был создан для JavaScript, но сегодня он поддерживает множество языков и форматов:
JavaScript (включая Flow), TypeScript, JSX, JSON, CSS, SCSS, Less, HTML, Vue, Angular, GraphQL, Markdown, YAML.

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

Пример форматирования



Вот как выглядит код до и после форматирования Prettier:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// До форматирования
function uglyCode  (a,b) {
if(a&&b){
return a+b;
}
else{ return a-b}
}
 
// После форматирования
function uglyCode(a, b) {
  if (a && b) {
    return a + b;
  } else {
    return a - b;
  }
}
Prettier автоматически добавляет отступы, пробелы вокруг операторов, форматирует блоки и расставляет фигурные скобки в соответствии с единым стилем.

Интеграция с редакторами



Максимальной продуктивности с Prettier можно достичь, интегрировав его с редактором кода:
VSCode: установите расширение "Prettier - Code formatter" и настройте автоматическое форматирование при сохранении.
WebStorm: встроенная поддержка Prettier с версии 2018.1.
Sublime Text: доступен плагин JsPrettier.

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

Как видим, Prettier — это не просто инструмент, а философия, которая предлагает перестать тратить время на субъективные аспекты форматирования и сосредоточиться на том, что действительно важно — на функциональности и качестве кода. В следующих разделах мы подробнее рассмотрим, чем Prettier принципиально отличается от линтеров и как эффективно совмещать его с ESLint.

Принципиальные отличия Prettier от линтеров



Разработчики JavaScript часто путают роли Prettier и линтеров наподобие ESLint. Эта путаница понятна — оба инструмента работают с исходным кодом и оба могут автоматически вносить изменения. Однако между ними существуют фундаментальные различия, понимание которых необходимо для создания эффективного рабочего процесса.

Фокус и назначение



Линтеры (ESLint, JSHint) выполняют статический анализ кода для обнаружения потенциальных ошибок, уязвимостей и нарушений принятых соглашений. Они проверяют такие аспекты, как:
Неиспользуемые переменные
Недостижимый код
Потенциальные ошибки в логике
Несоответствие принятым практикам
Нарушения архитектурных ограничений

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

Подход к обработке кода



Линтеры анализируют код и сообщают о проблемах (или исправляют их), не меняя структуру кода радикально. Они работают точечно, фокусируясь на конкретных паттернах, которые соответствуют заданным правилам.

Prettier действует иначе — он полностью переписывает код, игнорируя исходное форматирование. Можно сказать, что:
Линтеры вносят корректировки в существующий код
Prettier выполняет полную перепечатку кода

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Исходный код
function example( a,b )
{ return a &&
  b ? "yes": "no"; }
 
// ESLint с правилом исправления отступов
function example( a,b )
{ 
  return a &&
    b ? "yes": "no"; 
}
 
// Prettier (полностью переписывает)
function example(a, b) {
  return a && b ? "yes" : "no";
}

Настраиваемость и философия



ESLint невероятно гибок — он поддерживает сотни правил, каждое с множеством опций и уровней строгости. Вы можете настроить каждый аспект анализа под свои нужды, создать собственные правила или отключить те, которые вам не подходят.
Prettier, верный своей философии "меньше споров о форматировании", предлагает всего около 20 опций настройки. Его создатели намеренно ограничили возможности конфигурации, считая, что основная ценность — в унификации стиля, а не в соответствии личным предпочтениям.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Типичная конфигурация ESLint - десятки правил
{
  "rules": {
    "semi": ["error", "always"],
    "quotes": ["error", "single"],
    "no-unused-vars": "error",
    "react/jsx-no-bind": ["error", { "allowArrowFunctions": true }],
    // ... и так далее (часто сотни строк)
  }
}
 
// Типичная конфигурация Prettier - минимум опций
{
  "singleQuote": true,
  "printWidth": 80,
  "trailingComma": "es5"
}

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



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

Prettier тоже парсит код в AST, но делает это с единственной целью — переформатировать его. Такой подход обычно работает быстрее, особенно в режиме форматирования отдельных файлов при сохранении.

Область применения



ESLint больше всего полезен для:
  1. Обнаружения потенциальных ошибок.
  2. Обеспечения соответствия архитектурным ограничениям.
  3. Стандартизации кодовых паттернов.
  4. Внедрения лучших практик предметной области.

Prettier эффективен для:
  1. Устранения споров о стиле кода.
  2. Обеспечения единообразного форматирования.
  3. Улучшения читабельности кода.
  4. Упрощения процесса ревью кода.

Разрешение конфликтов



Когда и линтер, и форматер применяются к одному и тому же коду, могут возникать конфликты. Например, ESLint может требовать максимальную длину строки в 100 символов, а Prettier — в 80. Или ESLint может предлагать другой стиль расстановки пробелов, чем Prettier.

JavaScript
1
2
3
4
5
// Правило ESLint может требовать точку с запятой
const name = "John"  // ESLint: Missing semicolon
 
// Prettier может быть настроен на отказ от точек с запятой
const name = "John"  // Prettier отформатирует именно так
Именно поэтому рекомендуется конфигурировать ESLint так, чтобы он не конфликтовал с Prettier, о чём мы поговорим в следующем разделе.

Почему нужны оба инструмента



Часто спрашивают: "Если у ESLint есть правила форматирования, зачем нужен Prettier?" Ответ прост: каждый инструмент специализируется на своей задаче и делает её лучше других.
ESLint превосходен в выявлении потенциальных проблем с логикой, безопасностью и поддерживаемостью кода,
Prettier превосходен в обеспечении единообразного стиля без бесконечных дискуссий о форматировании.
Вместе эти инструменты создают мощный тандем, обеспечивающий и качество, и консистентность кода. ESLint следит за тем, чтобы код был корректным и соответствовал лучшим практикам, а Prettier гарантирует, что он будет единообразно отформатирован, независимо от личных предпочтений разработчика.

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

Стратегии решения конфликтов между ESLint и Prettier



Как мы уже разобрались, ESLint и Prettier — инструменты с разными целями, но пересекающимися сферами влияния. Когда они используются вместе, почти неизбежно возникают конфликты: правила форматирования ESLint могут противоречить решениям Prettier. Эти конфликты не просто раздражают — они могут привести к бесконечному циклу переформатирования, когда каждый инструмент пытается "исправить" изменения, внесённые другим.

Основные источники конфликтов



Типичные конфликты возникают вокруг:
  • Максимальной длины строки.
  • Использования пробелов vs табуляций.
  • Расстановки запятых и точек с запятой.
  • Отступов и пробелов в сложных конструкциях.
  • Стиля кавычек (одинарные vs двойные).

JavaScript
1
2
3
4
5
6
7
// ESLint правило: quotes: ["error", "single"]
const message = "Hello"; // ESLint потребует одинарные кавычки
 
// Prettier config: { "singleQuote": false }
const message = "Hello"; // Prettier переформатирует в двойные кавычки
 
// Результат: бесконечный конфликт

Три стратегии интеграции



Существует три основных подхода к решению конфликтов между ESLint и Prettier:

1. Отключение конфликтующих правил ESLint (eslint-config-prettier)



Самый популярный и рекомендуемый подход — использование eslint-config-prettier, который отключает все правила ESLint, связанные с форматированием, оставляя эту задачу полностью на Prettier.

Bash
1
npm install --save-dev eslint-config-prettier
JavaScript
1
2
3
4
5
6
7
8
// .eslintrc.js
module.exports = {
 extends: [
   'airbnb', // или любой другой пресет
   'prettier' // должен быть последним!
 ],
 // другие настройки
};
Принцип здесь прост: ESLint отвечает за качество кода, Prettier — за форматирование. Когда конфигурация prettier добавляется последней в массив extends, она отключает все правила форматирования, определённые в предыдущих конфигурациях.

2. Prettier как правило ESLint (eslint-plugin-prettier)



Альтернативный подход — использование Prettier в качестве правила ESLint с помощью eslint-plugin-prettier. Этот плагин запускает Prettier внутри ESLint и сообщает о различиях как о проблемах ESLint.

Bash
1
npm install --save-dev eslint-plugin-prettier
JavaScript
1
2
3
4
5
6
7
8
// .eslintrc.js
module.exports = {
 plugins: ['prettier'],
 rules: {
   'prettier/prettier': 'error'
 },
 // другие настройки
};
Этот подход удобен, когда вы хотите иметь единую команду и единый вывод ошибок. Однако он медленнее, поскольку каждый раз при проверке ESLint запускается и Prettier.

3. Последовательное применение (prettier-eslint)



Третий подход использует prettier-eslint — утилиту, которая сначала запускает Prettier для форматирования, а затем ESLint с --fix для корректировки кода по правилам, не связанным с форматированием.

Bash
1
npm install --save-dev prettier-eslint prettier-eslint-cli
JavaScript
1
2
3
4
5
6
// package.json
{
 "scripts": {
   "format": "prettier-eslint --write 'src/**/*.{js,jsx,ts,tsx}'"
 }
}
Этот подход более сложный и медленный, но даёт больший контроль в специфических ситуациях.

Рекомендуемая стратегия



Наиболее универсальное и простое решение — комбинация eslint-config-prettier и eslint-plugin-prettier:

Bash
1
npm install --save-dev eslint-config-prettier eslint-plugin-prettier
JavaScript
1
2
3
4
5
6
7
8
9
10
11
// .eslintrc.js
module.exports = {
 extends: [
   'some-other-config',
   'prettier' // отключает конфликтующие правила
 ],
 plugins: ['prettier'],
 rules: {
   'prettier/prettier': 'error' // запускает prettier как правило eslint
 }
};
Существует короткий путь настройки — пресет plugin:prettier/recommended:

JavaScript
1
2
3
4
5
6
7
// .eslintrc.js
module.exports = {
 extends: [
   'some-other-config',
   'plugin:prettier/recommended' // включает и плагин, и конфигурацию
 ]
};

Решение специфических конфликтов



Иногда даже при использовании eslint-config-prettier могут возникать конфликты, особенно при работе со специализированными плагинами. В таких случаях вы можете точечно настроить правила Prettier:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// .prettierrc
{
 "semi": false,
 "singleQuote": true
}
 
// .eslintrc.js
module.exports = {
 // ...
 rules: {
   // Отключаем правило semi в ESLint, т.к. Prettier настроен убирать точки с запятой
   'semi': 'off',
   
   // Настраиваем prettier как правило ESLint с теми же опциями
   'prettier/prettier': ['error', {
     'semi': false,
     'singleQuote': true
   }]
 }
};

Отладка конфликтов



Если вы всё ещё сталкиваетесь с конфликтами, полезно узнать, какие именно правила ESLint конфликтуют с Prettier. Для этого можно использовать команду:

Bash
1
npx eslint-config-prettier-check
Эта команда показывает список правил ESLint, которые могут конфликтовать с вашей конфигурацией Prettier.

Практический пример разрешения конфликта



Рассмотрим распространённый конфликт между правилом max-len в ESLint и обработкой длинных строк в Prettier:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
// ESLint хочет ограничивать длину строки
// .eslintrc.js
module.exports = {
 rules: {
   'max-len': ['error', { 'code': 80 }]
 }
};
 
// Prettier также имеет настройку длины строки
// .prettierrc
{
 "printWidth": 100
}
В этом случае, ESLint и Prettier будут конфликтовать. Решение:
1. Отключить правило max-len в ESLint или установить его в режим предупреждения.
2. Синхронизировать значения в обоих инструментах.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
// .eslintrc.js
module.exports = {
 rules: {
   // Снижаем до предупреждения, чтобы не блокировать коммиты
   'max-len': ['warn', { 'code': 100 }]
 }
};
 
// .prettierrc
{
 "printWidth": 100
}
Гармоничная интеграция ESLint и Prettier в рабочий процесс даёт команде лучшее из обоих миров: качественный, поддерживаемый код без бесконечных дискуссий о форматировании. Правильно настроенные инструменты работают незаметно, оставляя разработчикам больше времени на решение реальных проблем.

Автоматизация Prettier через Git хуки и CI/CD пайплайны



Ручной запуск форматирования кода хорош для начала, но в реальных проектах необходима автоматизация. Без неё даже в самых дисциплинированных командах неизбежно появятся несогласованности. Ключевые точки автоматизации Prettier — это Git хуки и CI/CD пайплайны.

Git хуки как первая линия защиты



Git хуки — это скрипты, которые Git запускает перед или после определённых событий. Для автоматизации форматирования кода особенно полезен хук pre-commit, который срабатывает перед созданием коммита:

Bash
1
2
3
4
5
6
7
8
#!/bin/sh
[H2].git/hooks/pre-commit[/H2]
 
files=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.jsx?$|\.tsx?$|\.css$|\.scss$')
if [ -n "$files" ]; then
  npx prettier --write $files
  git add $files
fi
Однако ручная настройка хуков неудобна: они хранятся в директории .git и не добавляются в репозиторий, из-за чего каждый член команды должен настраивать их самостоятельно.

Husky и lint-staged на помощь



Эту проблему решают инструменты husky и lint-staged:

Bash
1
npm install --save-dev husky lint-staged
Husky позволяет настраивать Git хуки через конфигурацию в package.json, а lint-staged ограничивает применение команд только файлами, которые включены в коммит:

JSON
1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js,jsx,ts,tsx,css,scss,json,md}": [
      "prettier --write",
      "git add"
    ]
  }
}
В более новых версиях Husky (≥6.x) конфигурация выглядит иначе:

Bash
1
2
3
4
5
# Инициализация husky
npx husky install
 
# Создание хуков
npx husky add .husky/pre-commit "npx lint-staged"
С такой конфигурацией перед каждым коммитом Prettier автоматически отформатирует все изменённые файлы, что гарантирует соответствие единому стилю без ручных действий.

Интеграция в CI/CD пайплайны



Git хуки отлично работают на локальных машинах, но не защищают от ситуаций, когда разработчик обходит их (например, с флагом --no-verify) или когда изменения вносятся через веб-интерфейс. Здесь на помощь приходит интеграция с CI/CD.

GitHub Actions



YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# .github/workflows/prettier.yml
name: Prettier Check
 
on:
  pull_request:
    branches: [ main, develop ]
 
jobs:
  prettier:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '16'
      - run: npm ci
      - name: Check formatting
        run: npx prettier --check "src/**/*.{js,jsx,ts,tsx,css,scss,json,md}"
Этот пайплайн будет проверять форматирование при каждом пул-реквесте и блокировать слияние, если код не соответствует стандартам.

GitLab CI



YAML
1
2
3
4
5
6
7
# .gitlab-ci.yml
prettier:
  stage: lint
  image: node:16
  script:
    - npm ci
    - npx prettier --check "src/**/*.{js,jsx,ts,tsx,css,scss,json,md}"

Автоматическое исправление в CI



Блокировать пул-реквесты из-за форматирования иногда излишне жёстко. Альтернативный подход — автоматически исправлять ошибки и коммитить изменения:

YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# .github/workflows/prettier-fix.yml
name: Prettier Fix
 
on:
  pull_request:
    branches: [ main ]
 
jobs:
  prettier-fix:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: ${{ github.head_ref }}
          token: ${{ secrets.GITHUB_TOKEN }}
      - uses: actions/setup-node@v2
        with:
          node-version: '16'
      - run: npm ci
      - name: Format code
        run: npx prettier --write "src/**/*.{js,jsx,ts,tsx,css,scss,json,md}"
      - name: Commit changes
        uses: stefanzweifel/git-auto-commit-action@v4
        with:
          commit_message: "style: apply prettier formatting"
          branch: ${{ github.head_ref }}

Стратегии автоматизации



При выборе стратегии автоматизации Prettier стоит учитывать несколько аспектов:
1. Строгость: Блокировать ли процесс при ошибках форматирования или автоматически исправлять их?
2. Последовательность: Применять ли одинаковые правила на всех этапах (локально, в CI, при деплое)?
3. Производительность: Проверять все файлы или только изменённые?

Для большинства команд оптимальный подход:
  • Использовать pre-commit хуки с lint-staged для автоматического исправления локально.
  • Запускать проверки в CI для дополнительной страховки.
  • Настроить автоматическое форматирование в отдельной задаче, которую можно запустить вручную.

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

JSHint: проверенный временем анализатор кода



В мире инструментов статического анализа JavaScript особое место занимает JSHint. Созданный в 2011 году как ответ на излишнюю догматичность JSLint, он быстро завоевал популярность благодаря более гибкому подходу к проверке кода. JSHint стал для многих разработчиков первым знакомством с миром линтинга и, несмотря на появление более совершенных инструментов, продолжает использоваться во многих проектах.

Философия и подход JSHint



JSHint был создан с философией «помогать, а не принуждать». В отличие от JSLint с его безапелляционным подходом, JSHint даёт разработчикам контроль над тем, какие правила применять к их коду. Этот подход резонировал с сообществом JavaScript-разработчиков, ценящих свободу выбора и гибкость. Ключевая особенность JSHint — прагматичность. Инструмент не пытается заставить всех писать в одном стиле, а концентрируется на выявлении реальных проблем, которые могут привести к ошибкам.

Базовая настройка и использование



Установка JSHint стандартна для npm-пакетов:

Bash
1
2
3
4
5
# Глобальная установка
npm install -g jshint
 
# Локальная установка в проект
npm install --save-dev jshint
После установки линтер можно запустить из командной строки:

Bash
1
2
3
4
5
# Проверка одного файла
jshint script.js
 
# Проверка директории
jshint src/
Конфигурация JSHint хранится в файле .jshintrc, который размещается в корне проекта:

JSON
1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "esversion": 6,
  "browser": true,
  "node": true,
  "undef": true,
  "unused": true,
  "strict": true,
  "maxdepth": 3,
  "globals": {
    "$": false,
    "jQuery": false
  }
}
Этот простой файл конфигурации указывает JSHint, что:
  1. Код использует возможности ES6.
  2. Код будет выполняться в браузере и Node.js.
  3. Следует сообщать о неопределённых и неиспользуемых переменных.
  4. Необходимо использовать строгий режим.
  5. Глубина вложенности блоков не должна превышать 3.
  6. $ и jQuery — глобальные переменные (флаг false означает, что их модификация запрещена).

Категории опций JSHint



JSHint организует свои опции в несколько категорий:

Enforcing Options (Ограничивающие опции)



Эти опции усиливают строгость проверки. Когда они включены (true), JSHint будет выдавать больше предупреждений:

JSON
1
2
3
4
5
6
7
{
  "curly": true,   // Требовать фигурные скобки вокруг всех блоков
  "eqeqeq": true,  // Требовать строгое сравнение (=== вместо ==)
  "noarg": true,   // Запрещать использование arguments.caller/callee
  "undef": true,   // Запрещать неопределённые переменные
  "unused": true   // Предупреждать о неиспользуемых переменных
}

Relaxing Options (Ослабляющие опции)



Эти опции, наоборот, снижают строгость. Когда они включены, JSHint будет выдавать меньше предупреждений:

JSON
1
2
3
4
5
6
7
{
  "asi": true,      // Подавлять предупреждения о пропущенных точках с запятой
  "boss": true,     // Разрешать назначения в условных выражениях
  "evil": true,     // Разрешать eval()
  "loopfunc": true, // Разрешать функции в циклах
  "shadow": true    // Разрешать переменные, затеняющие внешние
}

Environments (Окружения)



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

JSON
1
2
3
4
5
6
{
  "browser": true,  // Глобальные переменные браузера
  "node": true,     // Глобальные переменные Node.js
  "jquery": true,   // Глобальные переменные jQuery
  "mocha": true     // Глобальные переменные Mocha
}

Преимущества JSHint



Несмотря на появление более мощных инструментов, JSHint сохраняет ряд преимуществ:
1. Простота — JSHint прост в установке и настройке, что делает его хорошим выбором для небольших проектов и новичков.
2. Скорость — благодаря меньшему количеству правил и возможностей, JSHint работает быстрее более комплексных линтеров.
3. Стабильность — JSHint редко вносит радикальные изменения, что минимизирует необходимость обновления конфигурации.
4. Фокус на качестве кода — в отличие от ESLint с его множеством стилистических правил, JSHint концентрируется на предотвращении реальных проблем.

Интеграция JSHint



Как и другие линтеры, JSHint легко интегрируется с популярными редакторами и средами разработки:
VSCode: через расширение JSHint,
Sublime Text: через пакет SublimeLinter-jshint,
WebStorm: встроенная поддержка,
Vim: через Syntastic или ALE.
Также существуют плагины для интеграции с системами сборки:

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// Gulp
const gulp = require('gulp');
const jshint = require('gulp-jshint');
 
gulp.task('lint', function() {
  return gulp.src('./src/*.js')
    .pipe(jshint())
    .pipe(jshint.reporter('default'));
});
 
// Grunt
module.exports = function(grunt) {
  grunt.initConfig({
    jshint: {
      all: ['src/**/*.js']
    }
  });
  
  grunt.loadNpmTasks('grunt-contrib-jshint');
  grunt.registerTask('default', ['jshint']);
};

Ограничения JSHint



При всех своих достоинствах, JSHint имеет существенные ограничения по сравнению с современными линтерами:
1. Отсутствие плагинной системы — JSHint не поддерживает расширение через плагины, что ограничивает его применимость в проектах с нестандартными требованиями.
2. Ограниченная поддержка современного JavaScript — хотя JSHint поддерживает основные возможности ES6+, он отстаёт в поддержке новейших возможностей языка.
3. Отсутствие автоматического исправления — в отличие от ESLint, JSHint не предлагает механизма автоматического исправления обнаруженных проблем.
4. Ограниченная настраиваемость — количество правил и параметров значительно меньше, чем у ESLint.
5. Недостаточная поддержка фреймворков — отсутствие специализированных правил для популярных фреймворков, таких как React, Vue или Angular.

Где JSHint всё ещё актуален



Несмотря на конкуренцию со стороны ESLint, JSHint остаётся востребованным в определённых сценариях:
  • В проектах с устоявшейся кодовой базой, которые исторически используют JSHint.
  • В небольших проектах, где полнота возможностей ESLint избыточна.
  • В учебных целях благодаря простоте и понятности правил.
  • В средах с ограниченными ресурсами, где важна скорость работы линтера.

JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Пример кода с типичными предупреждениями JSHint
function calculateTotal(items) {
  var total = 0;  // JSHint: Используйте let/const в ES6
  
  for (var i = 0; i < items.length; i++) {
    var item = items[i];  // JSHint: Переменная, затеняющая внешнюю
    
    if (item.price == null) continue;  // JSHint: Отсутствуют фигурные скобки
    
    total += item.price * (item.quantity || 1);
  }
  
  return total;
}
Даже в эпоху доминирования ESLint, JSHint продолжает занимать свою нишу как надёжный, простой и быстрый инструмент статического анализа. Для многих проектов его возможностей вполне достаточно, а более лёгкая кривая обучения делает его хорошим выбором для начинающих разработчиков, только знакомящихся с концепцией линтинга.

История создания JSHint и его место в современной разработке



История JSHint неразрывно связана с его предшественником — JSLint, и фактически началась с разногласий о философии линтинга JavaScript. В начале 2010-х годов JSLint, созданный Дугласом Крокфордом, был доминирующим инструментом анализа кода JavaScript. Однако его подход "мой путь или никакой" вызывал недовольство в сообществе разработчиков.

В 2011 году Антон Ковалёв решил создать форк JSLint, который стал бы более дружелюбным к пользователям и давал бы им возможность выбора. Это решение было во многом спровоцировано конкретным инцидентом — Крокфорд изменил лицензию JSLint, добавив в неё неоднозначное требование: "Программное обеспечение должно использоваться только для Добра, а не для Зла". Эта формулировка не только вызвала юмор в сообществе, но и создала реальные проблемы для компаний, интегрирующих JSLint в свои продукты. Ковалёв вспоминал: "Когда я увидел эту лицензию, моей первой реакцией было недоумение. Как юристы могут интерпретировать понятие 'Зло'? И кто определяет, что такое 'Добро'? Это неприемлемо для серьёзного программного обеспечения". Так родился JSHint — с более открытой лицензией (MIT) и более демократичным подходом к линтингу. Название JSHint было выбрано как мягкая альтернатива тону JSLint: не "линт" (что подразумевает жёсткую чистку), а "намёк" на проблемы, которые разработчик может по своему усмотрению исправлять или игнорировать.

Первые версии JSHint были во многом похожи на JSLint, но с более гибкими настройками. Со временем JSHint эволюционировал, добавляя поддержку новых возможностей JavaScript и совершенствуя свой движок анализа. Важной вехой стала версия 1.0.0, выпущенная в 2013 году, которая принесла значительные улучшения производительности и стабильности. В то время JSHint быстро набирал популярность, становясь стандартом де-факто в мире JavaScript-разработки. Многие крупные компании и проекты, включая jQuery, Node.js и WordPress, использовали JSHint для обеспечения качества кода. Однако в 2013 году появился ESLint, созданный Николасом Закасом. Его плагинная архитектура и невероятная гибкость в конечном итоге изменили ландшафт JavaScript-линтинга. С 2015 года началось постепенное смещение популярности от JSHint к ESLint, особенно в новых проектах.

Несмотря на это, разработка JSHint не прекратилась. Проект перешёл в режим обслуживания, сосредоточившись на стабильности и поддержке устоявшейся функциональности, а не на конкуренции с более новыми инструментами. В 2017 году управление проектом перешло к Майку Шили, который продолжает поддерживать и обновлять JSHint до сегодняшнего дня.

На данный момент JSHint занимает особую нишу в экосистеме JavaScript — это надёжный, проверенный временем инструмент для проектов, которым не нужна вся мощь и сложность ESLint. В мире, где Prettier и ESLint стали стандартом для новых проектов, JSHint остаётся привлекательным выбором для поддержки устаревших кодовых баз и как более лёгкий альтернативный инструмент.

Интересный факт — некоторые команды по-прежнему выбирают JSHint именно из-за его ограничений. Когда важна скорость сборки и интеграции, меньшее количество правил и более простая архитектура JSHint могут быть преимуществом. Как отметил один из разработчиков на GitHub: "Мы переключились на JSHint после того, как ESLint с нашими правилами увеличил время сборки на 40%. Иногда меньше — значит больше". Другой аспект, который часто упускают из виду — воздействие JSHint на культуру разработки JavaScript. До JSHint многие разработчики вообще не использовали инструменты статического анализа, считая их слишком строгими или сложными. Более дружелюбный подход JSHint помог популяризировать саму идею линтинга кода среди широкого круга JavaScript-разработчиков. Можно сказать, что JSHint проложил дорогу для ESLint и других современных инструментов, сделав линтинг общепринятой практикой.

В современной экосистеме JS-разработки JSHint можно сравнить с надёжным, проверенным автомобилем, который хоть и не блещет новейшими функциями, но по-прежнему отлично справляется с своей основной задачей. В мире, зачастую гонящемся за новизной ради новизны, такая стабильность имеет свою ценность.

Сравнительный анализ инструментов



Выбор подходящего инструмента для анализа и форматирования кода — задача не из простых. ESLint, Prettier и JSHint решают схожие проблемы, но делают это по-разному и с разной степенью успеха в зависимости от конкретных требований проекта. Давайте сравним эти инструменты по нескольким ключевым параметрам, которые помогут определиться с выбором для конкретной задачи.

Производительность



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

JSHint традиционно считается самым быстрым из трёх инструментов благодаря своей простоте и ограниченной функциональности. Он не тратит ресурсы на поддержку плагинов и сложные трансформации AST, что делает его отличным выбором для больших проектов с ограниченными требованиями к анализу.
ESLint из-за своей плагинной архитектуры и широких возможностей конфигурации работает медленнее JSHint. Каждое правило — это отдельный модуль, который анализирует AST, что требует дополнительных ресурсов. Однако в последних версиях были внедрены значительные оптимизации, включая инкрементальную проверку и кэширование результатов.
Prettier обычно работает быстрее ESLint при форматировании отдельных файлов, но медленнее JSHint. Так как Prettier перепечатывает весь файл, независимо от того, сколько изменений нужно внести, он может быть менее эффективен для точечной проверки.

Примерное сравнение времени обработки 1000 файлов (в секундах):
JSHint: 5-10 секунд
Prettier: 15-20 секунд
ESLint: 20-40 секунд (зависит от количества правил)
ESLint + Prettier: 30-50 секунд

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

Bash
1
2
3
4
5
6
7
8
# Использование кэширования ESLint
eslint --cache src/
 
# Проверка только измененных файлов
git diff --name-only HEAD | grep '\.js$' | xargs eslint
 
# Паралельное выполнение
eslint-parallel src/

Функциональность и гибкость



ESLint безусловно лидирует по функциональности. Его плагинная архитектура позволяет расширять функциональность практически без ограничений. ESLint может проверять всё: от базового синтаксиса до сложных архитектурных ограничений, специфичных для конкретного проекта.
JSHint предлагает гораздо более ограниченный набор проверок, сфокусированных на выявлении потенциальных ошибок и несоответствий стандартам языка. Отсутствие возможности создания пользовательских правил и ограниченная поддержка новейших возможностей JavaScript сужают его применимость в современных проектах.
Prettier вообще не является линтером в традиционном понимании. Его задача — форматирование, а не анализ кода. Он не ищет потенциальные ошибки или плохие практики, а просто делает код единообразно отформатированным.

Интеграция с экосистемой



Все три инструмента хорошо интегрируются с основными редакторами и IDE, но глубина интеграции различается:

ESLint имеет наиболее глубокую интеграцию. Для VSCode, WebStorm и других популярных редакторов доступны полнофункциональные расширения, показывающие ошибки прямо в редакторе и предлагающие автоматические исправления. Кроме того, ESLint легко интегрируется с любыми системами сборки и CI/CD платформами.
Prettier следует за ESLint по уровню интеграции. Его главное преимущество — возможность автоматического форматирования при сохранении файла в большинстве редакторов. Эта интеграция обычно работает "из коробки" и требует минимальной настройки.
JSHint имеет базовую поддержку в большинстве редакторов, но часто с ограниченной функциональностью по сравнению с ESLint. Например, во многих редакторах отсутствует возможность автоматического исправления ошибок JSHint.

Совместимость с фреймворками



Современная JavaScript-разработка немыслима без фреймворков. Рассмотрим, насколько хорошо наши инструменты работают с популярными фреймворками:

React: ESLint имеет специальный плагин eslint-plugin-react, обеспечивающий полную поддержку JSX и специфичных для React паттернов. Prettier тоже прекрасно форматирует JSX. JSHint имеет лишь базовую поддержку JSX и требует дополнительной настройки.
Vue: ESLint предлагает официальный плагин eslint-plugin-vue, разработанный командой Vue. Prettier поддерживает форматирование Vue SFC через плагин. JSHint практически не имеет поддержки Vue.
Angular: Экосистема Angular тесно интегрирована с TSLint/ESLint через @angular-eslint. Prettier работает с Angular-шаблонами через специальный парсер. JSHint не имеет специальной поддержки Angular.
Node.js: ESLint и JSHint оба хорошо работают с Node.js-кодом через настройку окружения. Prettier, будучи форматером, работает с любым JavaScript независимо от среды выполнения.

Интересно отметить, что многие фреймворки и библиотеки поставляются с предустановленными конфигурациями ESLint. Например, create-react-app включает базовую конфигурацию ESLint, а Vue CLI предлагает опциональную интеграцию ESLint и Prettier.

Сообщество и экосистема



ESLint обладает самым большим и активным сообществом, регулярными обновлениями и богатой экосистемой плагинов и конфигураций. На GitHub у проекта более 20 000 звёзд и сотни контрибьюторов.
Prettier также имеет активное сообщество, хотя и меньше, чем у ESLint. Благодаря своему минималистичному дизайну Prettier требует меньше поддержки, но регулярно получает обновления и улучшения.
JSHint сегодня имеет значительно меньшее и менее активное сообщество. Обновления выходят реже, и новые возможности добавляются медленнее, чем в ESLint и Prettier.

Активность сообщества напрямую влияет на скорость исправления ошибок, поддержку новых возможностей JavaScript и интеграцию с новыми технологиями.

Выбор инструмента



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

На практике многие команды используют комбинацию ESLint и Prettier, где первый отвечает за качество кода, а второй — за форматирование. JSHint сегодня редко используется в новых проектах, но остаётся важным игроком в поддержке устаревших систем.

Практические рекомендации по внедрению инструментов анализа кода



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

Поэтапное внедрение в существующие проекты



Самая распространённая ошибка при внедрении линтеров — попытка сразу применить максимально строгие правила к существующей кодовой базе. Результат предсказуем: тысячи ошибок и предупреждений, деморализованная команда и отказ от использования инструмента.

Вместо этого рекомендуется постепенный подход:

1. Начните с режима уведомлений. Настройте ESLint или JSHint так, чтобы правила генерировали предупреждения, а не ошибки:

JavaScript
1
2
3
4
5
6
7
8
9
// .eslintrc.js
module.exports = {
 rules: {
   // Все правила только предупреждают
   'semi': 'warn',
   'indent': 'warn',
   'no-unused-vars': 'warn'
 }
};
2. Внедряйте правила маленькими группами. Начните с критичных правил безопасности и потенциальных ошибок, постепенно добавляя стилистические правила:

JavaScript
1
2
3
4
5
6
7
8
9
10
// Неделя 1: критические правила
{
 "rules": {
   "no-undef": "error",
   "no-global-assign": "error"
 }
}
 
// Неделя 2: добавляем проверку неиспользуемых переменных
// И так далее
3. Используйте правило "бойскаута": код должен становиться чище после каждого изменения. Попросите разработчиков исправлять предупреждения линтера в тех файлах, которые они и так изменяют.
4. Выделите отдельный PR/коммит для автоматических исправлений. Большинство стилистических проблем можно решить автоматически:

Bash
1
2
# Исправление всех автофиксируемых проблем
npx eslint --fix src/

Настройка для новых проектов



Для новых проектов процесс внедрения линтеров проще, так как нет технического долга. Вот оптимальная стратегия:

1. Выберите подходящие инструменты: для большинства современных проектов рекомендуется комбинация ESLint + Prettier.
2. Начните с популярного пресета и адаптируйте его под нужды проекта:

Bash
1
2
3
# Установка с Airbnb-пресетом
npx eslint --init
# Выберите "Use a popular style guide" -> "Airbnb"
3. Интегрируйте с Prettier, если используете его:

Bash
1
npm install --save-dev eslint-config-prettier eslint-plugin-prettier
JavaScript
1
2
3
4
5
6
7
// .eslintrc.js
module.exports = {
 extends: [
   'airbnb',
   'plugin:prettier/recommended'
 ]
};
4. Настройте Git-хуки для автоматической проверки и форматирования перед коммитом:

Bash
1
npm install --save-dev husky lint-staged
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
on
// package.json
{
 "husky": {
   "hooks": {
     "pre-commit": "lint-staged"
   }
 },
 "lint-staged": {
   "*.{js,jsx,ts,tsx}": [
     "eslint --fix",
     "prettier --write"
   ]
 }
}

Интеграция с CI/CD



Чтобы гарантировать соблюдение стандартов кода, интегрируйте линтеры в пайплайн непрерывной интеграции:

YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# .github/workflows/lint.yml (для GitHub Actions)
name: Lint
 
on: [push, pull_request]
 
jobs:
 lint:
   runs-on: ubuntu-latest
   steps:
     - uses: actions/checkout@v2
     - uses: actions/setup-node@v2
       with:
         node-version: '16'
     - run: npm ci
     - run: npm run lint
Для больших проектов рассмотрите возможность кэширования и параллельного выполнения для ускорения проверок.

Мониторинг и улучшение



После внедрения инструментов анализа важно отслеживать их эффективность:
1. Собирайте обратную связь от команды об эффективности правил.
2. Регулярно пересматривайте конфигурацию, добавляя или смягчая правила по мере необходимости.
3. Следите за новыми версиями используемых инструментов и обновляйте их, чтобы получить новые возможности и исправления.

Внедрение инструментов анализа кода — это не разовое мероприятие, а непрерывный процесс. Правильно настроенные ESLint, Prettier или JSHint становятся надёжными помощниками, постепенно повышая качество кода и продуктивность команды. Главный секрет успешного внедрения — баланс между строгостью правил и комфортом разработчиков.

Не могу установить плагин Eslint локально
Прохожу курс на ютуб по Жаваскрип. Лектор порекомендовал этот плагин. Он вроде как установился...

Как через правила ESLint настроить проверку имён файлов?
Здравствуйте. Нужно, чтобы при проверке eslint'ом выдавал ошибку, если файл/папка неправильно...

Cannot find module 'eslint-config-react-app/jest'
Происходит такая ошибка при вызове eslint. Подскажите, как решить? { &quot;name&quot;: &quot;projectnodejs&quot;, ...

Ошибка webpack с использованием eslint
Здравствуйте. Возможно что-то не так делаю или понимаю. Пытаюсь настроить eslint в проекте React +...

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

C++ На JavaScript (Перевод кода) - JavaScript
Всем привет помогите перевести код с C++ В JavaScript пожалуйста (Как можно быстрее,прошу): //...

Анализ выполнения JavaScript
Всем привет! Имеется сайт в котором контент выводится при помощи jQuery. Нужно проанализировать...

Анализ фрагмента кода
Здравствуйте! Помогите пожалуйста со следующей проблемой. Я ковыряюсь в чужом большом проекте и...

Анализ кода
Пишу дипломную работу по разработке системы распознавания фишинговых сайтов. И для начала собираю...

javascript внутри javascript
Здравствуйте. Помогите решить задачу. Нужно на html странице под спойлером в textarea поставить...

Вставка элементов меню (содержащих javascript) через javascript
Пишу курсовой проект по JavaScript в ходе которого потребовалось создать небольшой локальный сайт,...

Javascript - классы, они есть или их нету в Javascript?
Скажите, в Джаваскрипт есть классы как в пхп например? Я так толкового ответа порывшись по...

Размещено в Без категории
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Всего комментариев 0
Комментарии
 
Новые блоги и статьи
Генераторы Python для эффективной обработки данных
AI_Generated 21.05.2025
В Python существует инструмент настолько мощный и в то же время недооценённый, что я часто сравниваю его с тайным оружием в арсенале программиста. Речь идёт о генераторах — одной из самых элегантных. . .
Чем заменить Swagger в .NET WebAPI
stackOverflow 21.05.2025
Если вы создавали Web API на . NET в последние несколько лет, то наверняка сталкивались с зелёным интерфейсом Swagger UI. Этот инструмент стал практически стандартом для документирования и. . .
Использование Linq2Db в проектах C# .NET
UnmanagedCoder 21.05.2025
Среди множества претендентов на корону "идеального ORM" особое место занимает Linq2Db — микро-ORM, балансирующий между мощью полноценных инструментов и легковесностью ручного написания SQL. Что. . .
Реализация Domain-Driven Design с Java
Javaican 20.05.2025
DDD — это настоящий спасательный круг для проектов со сложной бизнес-логикой. Подход, предложенный Эриком Эвансом, позволяет создавать элегантные решения, которые точно отражают реальную предметную. . .
Возможности и нововведения C# 14
stackOverflow 20.05.2025
Выход версии C# 14, который ожидается вместе с . NET 10, приносит ряд интересных нововведений, действительно упрощающих жизнь разработчиков. Вы уже хотите опробовать эти новшества? Не проблема! Просто. . .
Собеседование по Node.js - вопросы и ответы
Reangularity 20.05.2025
Каждому разработчику рано или поздно приходится сталкиватся с техническими собеседованиями - этим стрессовым испытанием, где решается судьба карьерного роста и зарплатных ожиданий. В этой статье я. . .
Cython и C (СИ) расширения Python для максимальной производительности
py-thonny 20.05.2025
Python невероятно дружелюбен к начинающим и одновременно мощный для профи. Но стоит лишь заикнуться о высокопроизводительных вычислениях — и энтузиазм быстро улетучивается. Да, Питон медлительнее. . .
Безопасное программирование в Java и предотвращение уязвимостей (SQL-инъекции, XSS и др.)
Javaican 19.05.2025
Самые распространёные векторы атак на Java-приложения за последний год выглядят как классический "топ-3 хакерских фаворитов": SQL-инъекции (31%), межсайтовый скриптинг или XSS (28%) и CSRF-атаки. . .
Введение в Q# - язык квантовых вычислений от Microsoft
EggHead 19.05.2025
Microsoft вошла в гонку технологических гигантов с собственным языком программирования Q#, специально созданным для разработки квантовых алгоритмов. Но прежде чем погружаться в синтаксические дебри. . .
Безопасность Kubernetes с Falco и обнаружение вторжений
Mr. Docker 18.05.2025
Переход организаций к микросервисной архитектуре и контейнерным технологиям сопровождается лавинообразным ростом векторов атак — от тривиальных попыток взлома до многоступенчатых кибератак, способных. . .
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin
Copyright ©2000 - 2025, CyberForum.ru