Прошли очередные полгода с последних новостей о TARS (раз и два), а значит настало время поделиться новинками. Как всегда напомню, что TARS — это основанный на Gulp сборщик фронтенда, который помогает фронтенд-разработчику или даже целой команде создавать проекты любой сложности. Мы продолжаем уверенное шествие по России и не только. TARS уже используют в Нидерландах, Японии, Китае, Украине, Польше и других странах. Это можно заметить и по количеству звёзд на github, и по числу участников чата в gitter, и по количеству установок TARS-CLI за последний месяц (больше тысячи, а в пике больше 3 тысяч). Мы закрыли почти две сотни issue, выпустили два крупных обновления. Пользователи сборщика активно репортят, участвуют в разработке. Можно сказать, что у нас родилось маленькое сообщество.
Основные изменения
TARS стал по-настоящему, без каких-либо оговорок, модульным. Скорость запуска и сборки увеличилась в разы. К наиболее значимым изменениям относятся webpack и автообновление проекта (обновление версии сборщика, а не перезагрузка в браузере).
Наконец-то JavaScript можно собирать не только простой конкатенацией файлов. Даже стыдно было, что в 2016 году сборка скриптов в TARS была настолько отсталой. Webpack развязал руки в работе с JavaScript. Hot Module Replacement, который также поддерживается в TARS из коробки, творит чудеса. А с опцией injectChanges для стилей в Browser-sync разработка становится просто фантастической — браузер не перезагружается, а на лету применяет изменения в CSS и, если это возможно, в JavaScript. Если пойти дальше, то можно переложить работу со стилями и шаблонами на webpack. Так как любой таск в TARS теперь можно без труда переопределить — перенос ответственности за CSS и шаблонизацию легко реализовать с webpack. Если же говорить только о сборке JavaScript, то webpack тут предоставляет массу возможностей, о которых проще прочесть в документации. Кроме того, со второй версии (она находится в стадии beta-тестирования) появился Tree shaking, который позволяет импортировать в каждую точку приложения только тот код, который реально используется в модуле.
С приходом webpack в проект вы можете спросить, зачем вообще Gulp нужен, если всё можно сделать с помощью webpack и npm-скриптов? Ответ здесь очень простой: с Gulp всё гораздо проще.
На самом деле, про webpack вопрос не стоит — в TARS можно просто отключить таски, которые занимаются компиляцией шаблонов и сборкой CSS и использовать соответствующие лоадеры. Так что стоит перефразировать вопрос по-другому: зачем нужна некая абстракция в виде Gulp, когда его функции могут выполнять npm-скрипты?
Уже написано много статей, в которых объясняется вся мощь и преимущество npm. Постараюсь ответить на самые веские аргументы. Думаю, сразу стоит уточнить, что речь идёт о том случае, когда у нас много задач, между которыми есть зависимости в очерёдности выполнения.
Начнём с того, что вам придётся писать свою реализацию для запуска задач последовательно и параллельно. Зачем, если есть Gulp, который умеет это делать на «отлично»? К тому же иногда удобно работать с потоками при обработке какого-либо набора файлов. Либо вам придётся писать такую функциональность самому, либо просто отказаться от неё.
Серьёзный аргумент в пользу перехода на npm-скрипты — плохая поддержка плагинов для Gulp. Речь идёт о gulp-плагинах, которые являются обёрткой для различных модулей типа UglifyJS, PostCSS и т.д. Естественно, может быть небольшой «лаг» между, например, обновлением UglifyJS и gulp-uglify, но чаще всего это не существенно. Часто бывает так, что создатель Gulp-плагина и самого пакета, для которого этот плагин был написан, — одно лицо. Не исключается и тот факт, что кто-то может просто забросить свою разработку. В этом случае можно либо продолжить разработку за автора, либо использовать пакет напрямую, без gulp-обёртки. Таким образом работает webpack в TARS.
Ну, и напоследок: работа с тасками куда более приятна, нежели длинные портянки в package.json. Конечно, для проекта, в котором всего несколько задач, портянка вряд ли получится. В случае с TARS, когда мы пытаемся покрыть как можно больше потребностей разработчика одним инструментом и имеем сложные зависимости между последовательным и параллельным исполнением тасков, использование npm-скриптов не оправдывает себя, а, скорее, вставляет палки в колёса.
Gulp — это очень простая в использовании штука, протестированная в различных окружениях, на разных платформах. Для вас доступно всего 4 метода API и возможность создания сложного сценария параллельного и последовательного запуска тасков. В конце концов, вам даже не нужно знать, что под капотом находится именно Gulp, ведь TARS просто работает.
Если поддержка webpack уже давно реализована во многих проектах (а где-то сборщик построен только на webpack), то такой фичи, как автообновление проекта, не предоставляет никто. С TARS вы можете спокойно разрабатывать ваш сайт/сервис/что-то ещё и получать все последнии фичи TARS одной командой. При этом все настройки, файлы проекта, пользовательские таски и вотчеры будут сохранены. Ещё вчера вы конкатенировали JavaScript-файлы, а уже сегодня, обновив проект, получили возможность использовать webpack. Все шаги обновления логируются плюс есть возможность добавить свои команды, которые будут запущены при обновлении проекта.
Далее пойдут не столь значимые, но не менее полезные изменения.
Полезные мелочи
ESLint заменил JSCS и JSHint. Кстати, совсем недавно майнтейнер проекта JSCS Марат Дулин сообщил о переходе команды JSCS в проект ESLint. Так что, если вы ещё не используете ESLint, — самое время начать. Проверка кода стала проходить гораздо быстрее, с конфигом работать удобно — в общем, удобство со всех сторон.
Код TARS и TARS-CLI хорошенько отрефакторили и переписали на ES6 (с поддержкой тех фич, что доступны в 4 версии NodeJS). В целом всё стало чище и понятнее, надеемся, что pull request’ов в связи с этим станет больше. Основной gulpfile теперь радует глаз, потому что состоит всего из 30 строк. Так как код написан на ES6, пришлось отказаться от поддержки NodeJS версии ниже 4. Документацию привели в актуальное состояние, исправили много опечаток, ошибок и т.д.
Добавили возможность использовать SVG-символы. При этом есть возможность выбрать вариант подключения готового спрайта символов: вставить код спрайта в тело каждой страницы, держать все символы в отдельном файле, а при подключении указывать путь до этого файла (естественно, автоматически) или дать возможность вам самому реализовать подгрузку файла с символами.
Модули были переименованы в компоненты. При этом имя для папки с компонентами/модулями можно настроить в конфиге, если новое название вам не по душе. Появилась возможность вкладывать компоненты в компоненты. Эта фича также поддерживается и со стороны CLI-утилиты.
Было много просьб о том, чтобы можно было создавать компоненты с кастомной структурой с помощью CLI. Вы просили — мы сделали! Теперь можно описать схему компонента в json-файле, при этом схем можно сделать сколько угодно.
Почти все плагины, которые используются в TARS можно настраивать так, как удобно вам в одном общем конфигурационном файле.
Реализовали возможность компиляции стилей не автоматической конкатенацией, а с помощью точек входа, в которые вы можете импортировать только то, что потребуется в конечной сборке. Надеемся, что это даст больше свободы в работе со стилями.
Значительно ускорили пересборку Jade-шаблонов. Кэшируем теперь все, что можно и пересобираем только то, что действительно необходимо на данном этапе.
А самое главное — все эти нововведения вы можете получить просто запустив команду:
tars update-project
Ваш проект будет автоматически обновлен до последней версии с сохранением всех настроек.
Планы на будущее
Разработка TARS не останавливается, есть ещё много того, что хотелось бы реализовать:
- наконец уже перейти на 4 версию Gulp, когда она выйдет из beta-тестирования;
- перейти на вторую версию webpack, когда он выйдет из beta-тестирования;
- дать возможность использовать [Rollup](http://ift.tt/1d4XtPC) в качестве сборщика JavaScript;
- создать инфраструктуру для TARS-плагинов. Система плагинов — различные дополнения к TARS, которые нужны, чтобы решать «узкие» задачи. Самый простой пример — таски для вёрстки писем. Представьте, вы просто набираете «tars install tars-email» — и в ваш локальный TARS загружаются таски для комфортной работы с вёрсткой электронных писем;
- реализовать возможность использования PostCSS без каких-либо препроцессоров;
- реализовать поддержку css-модулей;
- наконец-то закончить промо-сайт;
- написать больше тестов на TARS и TARS-CLI.
Сейчас TARS развивается без потери совместимости с прошлыми версиями, из-за чего в новых версиях остаются сущности, от которых было бы неплохо избавиться. Хочется сломать эту совместимость, чтобы в следующей версии не осталось ничего лишнего. Обязательно реализуем механизм хотя бы полуавтоматического обновления с 1.x.x до 2.x.x.
За дальнейшими планами следите на github. Там же можно повлиять на проект. Мы всегда рады новым идеям. Пишите в gitter и на почту tars.builder@gmail.com В ближайшее время, возможно, появится канал в Slack и/или Telegram.
Комментарии (0)