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

Новость

Итак, в октябре прошлого года в блоге ESLint появляется пост:

Deprecation of formatting rules

В статье говорится о том, что в версии v8.53.0 стилистические правила станут устаревшими, но не будут удаляться ещё долгое время, как минимум до десятой версии ESLint, если не больше. Это значит, что сейчас у вас ничего не сломается, но и развивать эти правила в рамках плагина никто уже не будет. Разумеется, новые стилистические правила тоже не появятся.

Под стилистическими правилами, или, как их ещё называют, правилами форматирования подразумеваются правила, регламентирующие отступы, запятые, скобочки, формат строк и тому подобное.

Почему решили от них отказаться? Если отбросить всю лирику, то ответ простой: это требует слишком много времени и сил, а польза при всём при этом не столь велика.

Следом, разработчики typescript-eslint тоже решили отказаться от стилистических правил, объявив в версии v6.16.0 часть из них устаревшими. Они будут удалены в следующей мажорной версии, а именно седьмой.

Какие варианты поддержания единообразия кодовой базы рекомендуются разработчиками ESLint и typescript-eslint?

1. Использовать prettier.

2. Использовать dprint.

3. Использовать eslint stylistic.

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

Несмотря на такой исход стилистических правил, в случае, если вы уже используете eslint-config-prettier, который содержит правила форматирования в ESLint, удалять его будет преждевременно.

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

ESLint Stylistic — это плагин, унаследовавший стилистические правила от следующих плагинов:

• eslint

• typescript-eslint

• eslint-plugin-react

Как вы, наверное, догадываетесь, React сюда попал из-за правил форматирования JSX. Идея создателя stylistic-плагина в том, что все правила форматирования для JSX можно портировать в отдельный пакет, позволив переиспользовать стилистические правила другим JSX-фреймворкам, таким как Solid, Qwik, Vue и т. п., не устанавливая при этом плагин для React.

С другой стороны, на момент написания статьи разработчики eslint-plugin-react пока что не спешат переводить свои стилистические правила в «устаревшие».

Если вы всё же решили сохранить и перенести свои драгоценные, годами выверенные правила под покровительство нового stylistic-плагина, то следующая глава специально для вас.

Миграция

На выбор нам даётся два способа:

1. Использовать один плагин, совмещающий в себе JS, TS и JSX — этот способ является рекомендуемым.

2. Использовать три разных плагина — этот способ легче, по заверениям автора плагина.

Я не ищу лёгких путей, поэтому начал переносить правила JS и TS первым способом, JSX трогать не стал, решил подождать решение этого issue. Но путь всё равно оказался очень простым.

Если ваша eslint-конфигурация предусматривала работу с правилами JS и TS, то выглядеть конфигурация могла примерно так:

module.exports = {
  rules: {
    semi': 'error',
    // и так далее
  },
  overrides: [
    {
      files: '*.ts?(x)',
      rules: {
        'semi': 'off',
        '@typescript-eslint/semi': 'error',
        // и так далее
      }
    }
  ]
}

В результате миграции конфигурация становится даже проще:

module.exports = {
  rules: {
    '@stylistic/semi': 'error',
    // и так далее
  }
}

Правила, которые вам необходимо мигрировать, заботливо указаны для JavaScript тут, а для TypeScript — тут.

Но, например, @typescript-eslint/object-curly-spacing забыли, поэтому рекомендую опираться, в том числе, и на документацию stylistic-плагина, а именно на список перенесённых правил.

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

Больше про миграцию можно почитать тут.

Полезные ссылки

• Блог ESLint с новостью про отказ от поддержки стилистических правил.

• Блог typescript-eslint с новостью про отказ от поддержки стилистических правил.

• ESLint stylistic.

• Issue на eslint-plugin-react, за которым стоит последить в том случае, если вы его и так используете.

Мнение

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

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

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