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

Всем известный ESLint заведовал всеми правилами, но JavaScript продолжал усложняться: вышел ES6, появилась деструктуризация, стрелочные функции, async/await. Правила линтера для этих сложных вещей конфликтовали с правилами их оформления, это становилось сложно поддерживать.

Проблему решил Prettier в 2017 году. Он забрал на себя всё форматирование и сказал: "Мы придумали лучшие правила, берите и пользуйтесь, хватит спорить из-за стилей.". Действительно, спорить будет ли два таба или четыре пробела в начале строки - контрпродуктивно.

Таким образом, произошло разделение обязанностей. И если правила линтера продолжают быть темой споров, разные команды выкатывают свои конфиги в npm, какие-то наборы правил обрастают фанбазой, то с Prettier договариваться стало проще. Поставил и забыл.

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

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

Еще интересный факт, касательно линтера: когда правил много и кодовая база большая, это начинает сказываться на производительности. Редактор кода может тупить, медленнее сохранять файлы, не сразу обрабатывать код и давать подсказки. Один из способов, которым это пытаются решить - переписать линтер и его правила на Rust. Например, Oxlint. Скорость работы в десятки раз выше, но на тот момент, когда я в этом разбирался, не было переписано еще очень большого количества правил, потому мы использовать не стали. Но может кому-то будет интересно.

#Javascript #eslint #formatter #linter #Oxlint #Prettier