Putout: линтер нового поколения

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


    История линтеров


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



    Что не так с существующими линтерами


    В JavaScript Community все более-менее утряслось, и остался один линтер, выживший либо вмердживший в себя конкурентов. ESLint и правда делает очень многие вещи достаточно качественно. Но все не так просто, и есть набор моментов, который, скажем так, можно было бы улучшить:


    1. Нет состояния прогресса. В 2020-ом году, мы каждый день запускаем инструмент, который неизвестно когда завершит работу. Да, на маленьких проектах это не заметно и не существенно. Но фронтенд сейчас очень сильно разросся, и плагинов, и правил существует довольно-таки много, и проверка может вполне выполняться несколько минут. Как минимум, это не удобно.
    2. Переусложненная система плагинов. Да она быстрая, эффективная, но очень уж многословная:
    3. Наличие такой концепции как warning: зачем? Если нашел проблему — возьми и исправь, зачем о ней говорить, помечая желтым цветом. Постоянные напоминания о чем-то, что не сильно важно не имеют смысла.
    4. Отсутствие опции --fix для огромного количества правил. Это сейчас ESLint двигается в сторону autofix, но делает он это крайне плавно, и само наличие правил, которые не исправляются сами, лично меня напрягает.

    В чем ключевая идея Putout


    Владея основной информацией о том, что не так с существующими решениями, было решено сделать продукт в соответствии со следующими принципами:


    1. Возможность отображения статуса прогресса.
    2. Каждое правило имеет возможность исправления.
    3. Правила могут минимально менять поведение кода, если это делает его лучше.
    4. Правила имеют полные и конкретные названия (convert-equal-to-strict-equal в противовес eqeqeq).
    5. Нет ворнингов, есть только ошибки.
    6. Максимально дополнять ESLint, не дублируя его работу, косметические правки имеет смысл оставить ему.
    7. 100% покрытие тестами (сейчас их более 1400)
    8. Писать и тестировать плагины должно быть просто и легко.
    9. Маленькое ядро, вся система состоит из плагинов.
    10. Интеграция с существующими решениями.

    Архитектура


    image


    Основной механизм работы Putout состоит из работы трех модулей:


    • parser — парсит код в AST, а затем AST обратно в код
    • loader — загружает плагины
    • runner — запускает на выполнение плагины

    Плагины


    Встроенные плагины поддерживают 4 вида интерфейсов, начиная от самых простых, и заканчивая сложными. Благодаря этому putout содержит в себе больше 50 плагинов, каждый из которых является отдельным npm-пакетом, то есть при обновлении плагина, update придет пользователям более старых версий Putout наравне с пользователями новых версий.


    Интеграция с существующими решениями


    Putout поддерживает все самые популярные парсеры JavaScript кода, а так же системы написания кодмодов, такие как jscodeshift. Кроме этого может использоваться как плагин для ESLint (благодаря чему попадает во все IDE), плагин для babel, а также имеет возможность запуска ESLint для форматирования файла, после внесения изменений, а так же встроенную поддержку работы со staged файлами в git и улучшенную работу кэша (кэшируются результаты проверки всех правил Putout, и только встроенных правил ESLint).


    Послесловие


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

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 5

      +1

      Putout, Putin.

        +1
        Наличие такой концепции как warning: зачем?

        Добавляю я новое правило в приложение (не использовать deprecated API), eslinter пишет о >100 ошибках. Для исправления нужно переписывать логику, на что сейчас времени нет. Помечаю как warning для того чтобы коллеги не создавали новых ошибок. +если я буду редактировать файл/метод — увижу что нужно порефакторить код.
          0

          Плюсы в этом подходе безусловно есть, однако у Putout подход диаметрально противоположный: вместо того, что бы закидывать 100 сообщений (которые разработчики очень быстро перестанут читать, захлебнувшись в потоке информации, ибо слишком много информации = 0 информации), берет и исправляет то что нашел, либо не исправляет и молчит :).


          Еще есть возможность написать кодмод, который будет в автоматизированном режиме править deprecated методы, гораздо более простым способом, чем делая это с помощью ESLint. Такой подход, например, применяется для правил Putout, с помощью плагина @putout/plugin-putout.


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

            0

            Так а разве это всегда возможно? Ну, то есть, некоторые ошибки можно вычислить, но их не просто пофиксить автоматически.

              0

              На всех проектах, которых я работал, ворнинги не использовались никогда :). И так получалось, что не имело значения: это фронт на angular/react, бэк на node.js, либо больше 200-та npm-пакетов. Правило либо исправляется, либо отключается до лучших времен — все просто. В статье об этом было сказано для того, что бы показать фундаментальные отличия в философии инструментов.


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


              Однако, если разработчику удобнее с ворнингами и это делает код лучше, а работу продуктивнее — то, пожалуйста, это личный выбор каждого :).


              С помощью плагина eslint-plugin-putout возможно использовать ESLint с привычными ворнингами совместо с Putout, который исправить может все, что найдет, при этом показывая только ошибки.

        Only users with full accounts can post comments. Log in, please.