Продолжаем бороться с frontend-рутиной

    image

    Прошло полгода с последней новости о TARS на хабре.

    Напомню, что TARS — это сборщик html-верстки, основанный на gulp, в помощь любому frontend-разработчику (или даже целой команде), для создания проектов любой сложности. За последние шесть месяцев было закрыто 88 issue, выпущено 7 версий, появился CLI, так вышло, что с yeoman’ом отношения не сложились, поэтому появилась своя версия. TARS переехал в свой новый дом на github, обзавелся командой из 4 разработчиков + небольшой армией фанатов. Кстати, огромное вам спасибо за мгновенные фидбеки после релизов и не только. TARS был внедрен в нескольких вебстудиях России и за рубежом. Сборщик научил компонентному подходу не один десяток разработчиков, привлек в ряды frontend’еров тех, кто боялся всей рутины верстки. В общем, появилось много всего нового, и об этом хотелось бы рассказать.

    Небольшой план статьи:
    • кратенько напомним о том, что такое TARS;
    • поговорим о новинках;
    • поговорим о том, что чаще всего понимают не так. Как использовать TARS, чтобы получить максимум пользы;
    • что ждет проект впереди;
    • слова благодарности.

    Что такое TARS?


    Итак, для начала все же ответим на вопрос, что такое TARS, более развернуто. Небольшая копипаста из прошлой статьи: «TARS — это набор gulp-тасков для автоматизации большинства задач frontend’а + возможность лёгкого добавления новых, если будет чего-то не хватать. TARS можно назвать фреймворком для gulp. Подходит как отдельным разработчикам, так и большим командам. С ним легко разрабатывать проекты любой сложности: от лендинга до огромного портала. Вам даже не нужно знать, как работает gulp, так как всё что можно было вынесено в опции, весь код и варианты использования задокументированы.

    Больше информации можно получить из прошлой статьи и записи выступления с FrontTalks.



    Что нового?


    Прежде всего скажу: используйте новинки с любой версией TARS, так как в рамках одной мажорной версии гарантируется 100% совместимость вашего проекта. Гайд по обновлению в документации проекта.

    Главная новинка — это CLI для TARS. Что представлял проект на TARS до появления CLI: файлы проекта + все node_modules для TARS. И так в каждом проекте. Размер каждого увеличивался до 250 МБ, что было крайне неудобно, если проектов больше 5. При создании нового проекта на Windows зависимости устанавливались более 5 минут.

    Необходимо было помнить названия команд, название ключей, не было проверки правильности используемых ключей, что можно использовать вместе, а что нет. В общем, одну рутину TARS убирал и добавлял немного другой. Чтобы это исправить, мы создали TARS-CLI.

    TARS-CLI — npm-пакет (ставится глобально), который позволяет:
    • заинитить проект;
    • запускать таски для сборки (как дев, так и релизной) проекта;
    • добавлять модуль в проект с различным набором файлов и папок, больше не нужно делать это руками;
    • добавлять страницы в проект, как копии существующего шаблона, так и абсолютно пустые;
    • запускать вообще любой таск из gulpfile.js в текущей директории.

    При запуске команды с некорректными флагами вы получите сообщение об ошибке. При инициализации проекта теперь не нужно руками править tars-config.js, достаточно ответить на пару вопросов в весьма удобном (для консоли) интерфейсе. При этом сохранили работу с флагами, если вам не хочется каждый раз выбирать режим работы или вы производите автоматическое тестирование. Как и TARS, у TARS-CLI хорошая документация на двух языках: русском и английском. Перевод документации (как для CLI, так и для основного проекта) на английский — тоже новинка. Причина перевода — TARS заинтересовал разработчиков из Чехии, США, стран Южной Америки. Не солидно не иметь документации на английском языке.

    Общий список наиболее значительных изменений:
    • добавили поддержку Babel;
    • поддерживается директива import, sourcemaps, несмотря на то, что происходит конкатинация стилей;
    • добавили поддержку PostCSS;
    • ускорили процесс сборки;
    • вычистили уйму багов, провели серьезный рефакторинг, добавили много полезных мелочей.

    На самом деле, список изменений куда больше. Новые пользователи хорошо повлияли на развитие TARS. Мы реализовали новые идеи, приняли pull request’ы, а один из разработчиков через TARS устроился работать в 2ГИС.

    Также стоит упомянуть, что каждый релиз теперь проходит через автоматическое тестирование на Windows, Linux и OS X, что позволяет выпускать более надежный код. Статус сборки выводится на бейджи в readme проекта.

    Кстати, сборщик успешно применятся для разработки приложений на Cordova, расширений для браузеров и т.д.

    FAQ


    Для разработки желательно использовать именно TARS-CLI. Если вы практикуете сборку проекта на сервере, то используйте TARS отдельно. В этом случае не будет глобальных зависимостей. Но и TARS-CLI использовать никто не мешает.

    Вместе с TARS-CLI можно использовать любую сборку TARS. Форкайте, добавляйте таски, модифицируйте сборщик, чтобы он покрывал ваши нужды. Чтобы заинитить проект, выполните:

    tars init -s http://url.to.zip.with.tars
    

    Таким образом, TARS-CLI — интерфейс к TARS, с которым стало гораздо удобнее. Теперь перейдем к самым частым вопросам и недопониманиям, которые мы получали по почте или в гиттер.

    Вопрос: можно ли пользоваться TARS без опаски, что останусь у «разбитого корыта»? Не будет ли проект заброшен?
    Ответ: пользоваться точно можно без опаски. Проблемы могут встречаться, но все они решаемы. В самом крайнем случае наша команда сможет сбилдить вам проект и отправить на почту. Ближайшее время планируется сделать сервис онлайн сборки, если локально что-то пошло не так. Бросать проект мы точно не собираемся, каждую неделю появляются новые issue + вторая версия на носу. Ни нам, ни вам скучать не придется. За последний месяц TARS-CLI поставили больше тысячи человек, если верить статистике из npm.

    Вопрос: у нас в команде есть свой сборщик на gulp/grunt, хотелось бы использовать наработки из него в TARS.
    Ответ: можете перенести необходимые таски в user-tasks. Для использования grunt-тасков, если не хотите переписывать на gulp, есть пакет gulp-grunt, который запускает grunt-таск в gulp. Но все же рекомендуем портировать grunt-таск в gulp. Тем более, все плагины для grunt доступны в gulp. Если необходимо, чтобы проект инитился всегда с этими дополнительными тасками, то рекомендую создать форк TARS, добавить в нем необходимые изменения, инитить проект, с указанием ссылки на ваш форк. При этом, для упрощения обновления форка, все кастомные таски следует складывать в users-tasks, а зависимости для этих тасков указывать в user-package.json. Они будут ставится с каждым заиниченым проектом.
    Кроме того, если ваши таски будут полезны большому числу разработчиков, очень просим сделать pull request. Описание, как с нами работать, доступно по ссылке.

    Вопрос: как лучше построить процесс разработки с помощью TARS?
    Ответ: единого ответа тут нет. Все зависит от специфики разработки.

    Рассмотрим несколько типов проектов.
    1. Долгоиграющий и единственный. В этом случае все просто. Создавайте модули, страницы, храните все в какой-либо CVS — в общем, этот сценарий самый скучный.
    2. Много проектов с повторяющейся функциональностью. В этом случае есть несколько путей работы с TARS.
      • Создать библиотеку переиспользуемых блоков и включить ее сразу в собственный форк TARS. Таким образом, при ините нового проекта в нем сразу будут все нужные блоки.
      • Использовать git или любую другую CVS. Пусть заиниченный TARS находится в git, а каждый новый проект — отдельная ветка.
      • Хранить библиотеку повторяющихся блоков отдельно.

      Первый вариант самый удобный. Но в этом случае нужно следить за состоянием форка и вовремя брать изменения из оригинального репозитория.
    3. Много разных проектов. Также весьма простой сценарий, при котором каждый проект может быть отдельным репозиторием в git (или другой CVS).

    Указанные способы выше — не догма, а лишь пример, как получить больше пользы от TARS.

    Вопрос: кажется, что стек технологий, который вы предлагаете — это прошлый век. Все уже на webpack пересели, а скрипты через npm запускают без всяких gulp/grunt/broccoli/что-то еще.
    Ответ: начнем с того, что тот же gulp имеет на github более чем в два раза больше звезд, чем webpack или что-то подобное. Называть gulp устаревшим — это как минимум не корректно. Для каждой задачи есть свои инструменты.
    Если у вас очень простой проект, вам нужно только стили склеить, да js сжать, то можно написать все самому и запускать через npm. А можно не тратить время на это и заниматься собственно проектом, а все остальное поручить инструментам, которые как раз сделаны для этих нужд. На самом деле, удивляет, что разработчики готовы использовать менеджер пакетов, как таск-раннер. Но это уже вкусовщина.
    Вернемся к вопросу о webpack. Ничего не мешает использовать gulp вместе с webpack. Собственно в планах есть внедрение или webpack, или browserify.

    Вопрос: ничего не понятно, какие-то модули, страницы, куча ошибок, ничего не ставится, что происходит вообще?
    Ответ: почитайте документацию на русском или английском. Или напишите на почту tars.builder@gmail.com или в наш чатик в gitter. Все оперативно фиксим. Обратная связь будет совсем не лишней, так что если вы обнаружили какую-либо ошибку в работе сборщика, сообщите о ней

    Планы на будущее


    За дальнейшими планами следите на github. Там же можно и повлиять на проект. Мы всегда рады новым идеям.

    В самое ближайшее время мы планируем:
    • сделать промо-сайт;
    • webpack, browserify, что-то ещё;
    • переехать на четвертую версию gulp, когда ее выпустят;
    • дать возможность собирать React-приложения;
    • сделать онлайн версию сборщика;
    • начать работать над второй версией TARS;
    • создать инфраструктуру для TARS-плагинов.

    Последние две идеи — самые интересные. Если со второй версией еще пока не все ясно, то про плагины уже можно рассказать. Система плагинов — различные дополнения к TARS, которые нужны, чтобы решать «узкие» задачи. Самый простой пример — таски для верстки писем. Представьте, вы просто набираете tars install tars-email, и в ваш локальный TARS загружаются таски для комфортной работы с версткой электронных писем.

    В ближайшее время мы научим TARS разговаривать. Правда синтетическим голосом и только на Mac и Linux. Попробуем добавить ему характера, научим сарказму. Естественно, это все будет опционально: если вы захотите тишины — достаточно поменять 1 опцию в конфиге.

    Credits


    В конце благодарности: Lence_l за кропотливую работу над документацией и ее переводом, owanturist за работу над js-тасками, oleks за отличные идеи и помощь в разработке, всем ребятам из гиттера за мгновенные фидбеки, после выпуска очередной версии сборщика, за отличные идеи и поддержку.

    Пользуйтесь, форкайте, ставьте звездочки в github и продолжайте уменьшать уровень frontend-рутины с TARS.
    2ГИС 166,30
    Карта города и справочник предприятий
    Поделиться публикацией
    Похожие публикации
    Комментарии 10
    • 0
      Давно уже использую babelify и присматриваюсь к SystemJS.
      Не хотите добавить рутину для первого старта в package.json, чтобы можно был просто фыр-фыр-фыр выполнить npm run init и получить CLI вместе с первой сборкой/конфигом?
      • 0
        Не совсем понял, откуда этот package.json появится? Сейчас нужно только 1 раз CLI установить и дальше только tars init. Уточните, пожалуйста, про какой package.json идет речь?
        • 0
          Выкачал я TARS из репозитория, а мне же нужно установить зависимости с помощью npm install, которые в package.json. Да еще потом CLI ставить и делать первую сборку. Это и еще что-нибудь можно собрать в одну команду — клонировали репозиторий, выполнили одну команду и готово, дальше пользуем CLI. Могу ошибаться в желании уменьшения энтропии, поэтому уточню — еще не пробовал.
          • 0
            Нет необходимости выкачивать TARS из репозитория. CLI был создан в первую очередь, чтобы этот шаг не делать. Нужно только поставить глобально TARS-CLI, затем tars init в любой рабочей директории сделает все сам + еще и спросит всю нужную информацию для init.
            Наверное это не очень прозрачно из документации, раз возник такой вопрос?
            • 0
              Да, мне кажется стоит добавить очевидности в основной репозиторий. Я смотрел зависимости CLI и четко видел там то же самое из оных для TARS, потому был немного озадачен до того как покопался.
              А что насчет babelify и systemjs? Мне кажется это было бы лучшим вариантом, чем заморачиваться на другое.
              • 0
                Пожалуй еще поработаю над докой, спасибо.
                Предложение интересное, тоже обязательно его рассмотрю. Сейчас как раз занимаюсь поддержкой require/import
      • 0
        Ни холивара ради, просто личный опыт: gulp — очень хороший и классный инструмент, верой и правдой служил и помогал мне в печали и радости, но после перехода на webpack в совокупности с автоматизацией через npm-скрипты, я фактически больше не имею с gulp никаких дел, т.к. необходимость в нем отпала.
        • 0
          На момент создания TARS не все можно было сделать с помощью webpack. К тому же gulp — проверенный инструмент, который не подводил, с которым было легко работать. Собственно TARS + gulp свою работу делают на отлично. Еще одним важным аргументом было то, что gulp куда более популярен (даже на данный момент), и хотелось, чтобы каждый мог переиспользовать свои наработки.
          Возможно во второй версии TARS будет webpack, но gulp и сейчас еще ого-го) К тому же разработчики gulp проект развивают и бросать даже не думали.
          • 0
            Артём, конечно же я не могу сказать, что gulp устарел и что решения построенные на нем на данный момент неактуальны. И речь вовсе не конкретно о TARS, а в целом — gulp отлично справляется со своими обязанностями, и особенно приятен и понятен для тех, кто только открывает для себя всю эту кухню. Но есть мнение, что имея под рукой грамотный сборщик, покрывающий большую часть задач и мощь npm-скриптов — таск-раннеры в общем то и не нужны.
            Мне ни в коем случае не хотелось бы выглядеть тем, кто призывает отказываться от Gulp, но тем не менее, насколько я могу судить, тенденция проглядывается )
            Не удивлюсь, если после внедрения webpack, вы сочтете, что большую часть тасков можно будет просто убрать, а оставшуюся легко реализовать без gulp.
            В любом случае, успехов.
            • 0
              Может быть так и случится.
              Спасибо)

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое