Task runner что это

[Перевод] Введение в Gulp, Grunt, Bower, и поддержка npm в Visual Studio

Вступление

Веб разработка, а именно фронт-энд разработка становится, как и традиционная бэк-энд разработка, все комплекснее и мудренее. Множество проектов нуждаются в большем, нежели банальная закачка пары JS и CSS файлов по FTP. Сейчас мы можем наблюдать так называемый процесс сборки фронт-энда, который может включать компиляцию SASS и LESS, сжатие CSS/JS, запуск JSHint или JSLint и многое другое. Эти сборочные задачи и процессы координируются такими инструментами как Gulp или Grunt. Так же клиентскими библиотеками можно управлять используя различные системы управления пакетами как npm или bower.

Для чего ASP.NET клиентские системы управления пакетами? Почему не NuGet? Почему не MSBuild?

Некоторые из вас задаться вопросом — «а почему же не использовать JavaScript с NuGet?». Или например, «почему бы не написать еще одно расширение MSBuild для сборки CSS/JS?».

Все просто. Потому что уже существует богатая экосистема заточенная под такого рода задачи. NuGet хорош для серверных библиотек (ну иногда и для клиентских может сгодится), но существует чертовски больше CSS и JS библиотек под npm и bower, приспособленных под это дело. MSBuild хорош для сборок ориентированных на стороне сервера, но может быть большим излишеством для сборки клиентских приложений.

Ну так как насчет использовать оба решения. Для этого есть предусмотренные инструменты. Добавление поддержки Gulp, Grunt, Bower и npm (ну и других плюшек, если понадобится в будущем) означает более адаптированную среду для фронт-энд разработчиков, работающих с ASP.NET. А так же это открывает двери для разработчиков ASP.NET в познании и использовании JS и CSS библиотек которые повседневно используются фронт-энд сообществом.

Введение в диспетчер запуска задач(Task Runner Explorer)

Мы получили целую тонну запросов касающихся поддержки Grunt/Gulp от многих из вас и так же от сообщества в целом. Мы работаем над высококачественной поддержкой обоих менеджеров Grunt и Gulp в Visual Studio «14», с полной расширяемостью. Сейчас мы готовы представить вашему вниманию предварительную версию, вышеописанной поддержки, в виде расширения для VS2013 и мы будем рады если вы поможете нам, знакомясь и тестируя данное расширение.

Сегодня мы представляем предварительно-ознакомительную версию нашего Диспетчер Запуска Задач в виде VSIX — расширения. Мы так же рекомендуем вам, два других VSIX — расширения для более удобного использования, представленного нами, функционала.

На заметку:

Большинство функционала, включенного в эти несколько VSIX — расширений будут включены в Visual Studio, таким образом, вам не придется все их ставить в будущем. Все таки для данной предварительно-ознакомительной версии для VS2013 нам необходимы все эти расширения для того что бы представить вам наше решение в короткие сроки. Так же обратите внимание что на сегодняшний момент в Visual Studio Express будет работать только Task Runner Explorer, но начиная с VS14 весь функционал будет работать в свободной версии Visual Studio.

Рассматривайте выше-переставленный набор функций как предварительную, DevLabs версию нежели чем что-то финальное и готовое решение из раздела VS Productivity Power Tools. Все это будет достигнуто в финальной версии продукта.

Что вам нужно?

Для того что бы открыть TRX (Task Runner Explorer), просто выполните правый щелчок мышью на gruntfile.js файле в вашем проекте:

TRX обычно находится на нижней панели в VS и выглядит вот так:

Здесь видно что gruntfile.js был найден в корне одного и более проектов в решении. Здесь так же отображается функционал который позволяет вам запускать задачи реагируя на 4 разных события Visual Studio.

Для ассоциации цели или задачи с событием Visual Studio, просто выполните нажатие правой кнопки мышкой и выполните связывание:

Для запуска цели или задачи просто кликните на последней и пред вами предстанет следующий терминал:

После установки расширения автозаполнения для менеджера пакетов вы заметите как легко добавить или обновить тот или иной пакет при правке вашего package.json для bower или npm.

Вы так же сможете лицезреть асинхроные всплывающие подсказки заполненные мета-данными.

Когда вы начнете тестирование помните что вам нужно запустить npm install перед использованием TRX для запуска задач Grunt.

Источник

Ускоряем npm-скрипты

Таск раннеры существенно упростили жизнь веб разработчиками автоматизируя рутинные действия связанные с запуском тестов, проверкой кода, объединением в один файл, транспайлингом и прочими не менее полезными делами. Опустим вопрос необходимости подобных инструментов, конечно, можно и без них, но они существенно упрощают жизнь и делают более качественным процесс разработки.

Все пользуются таск раннерами в той или иной мере: кто-то старинным грантом, кто-то постепенно уходящим с арены галпом и многими другими, а кто-то уже во всю использует npm-скрипты.

Последние мы сегодня разберем во всех деталях, а так же способы их ускорения и расширения возможностей

Причины использовать npm как таск раннер

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

По мере появления перечисленных выше таск раннеров, они были мной испробованы в бою, и в каждом из них (конечно же) есть плюсы, и минусы. Рассмотрим их вкратце.

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

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

После чего сам gulp, и его плагины начали обновляться, а потом и его зависимости, которые бывало нужно было обновлять самостоятельно. Конечно можно не использовать сервисы, следящие за обновлениями пакетов, устранением уязвимостей, исправлением ошибок и всем прочим, но это не самый хороший подход к разработке.

Таким образом мы подошли к главному недостатку большинства такс раннеров: их нужно обновлять, их зависимости нужно обновлять и зависимость зависимостей тоже. Для монолитных приложений это не представляет проблемы. Проблемы начинаются тогда, когда частей приложения много, и каждая из них является независимым модулем, а это ли не основная парадигма разработки на node.js?

Итак, вместо того, что бы обновлять: gulp, gulp-jshint и jshint, я лучше просто буду использовать jshint напрямую, с помощью интерфейса командной строки, который не часто меняется, значительно упрощая себе этим жизнь.

npm-скрипты

Когда я начал активно использовать npm-скрипты, я, как и многие разработчики, осознал неудобство и многословность такого подхода, к примеру, если нужно организовать проверку линтерами, код будет выглядеть таким образом:

Тогда скрипт, который запускает все проверки будет выглядит так:

Очень уж многословно, а тут всего-то 3 скрипта запускаются.

Удобные npm-скрипты

npm-run-all

Предыдущий пример получился очень многословным (гораздо более коротким чем в случае с грантом и галпом, но тем-не-менее) и сложночитаемым. npm-run-all существенно все упрощает. С его помощью, код делающий тоже самое будет выглядеть так:

И делать примерно то же самое: поочередно запускать скрипты.

npm-run-all очень не плохо себя показывает в плане удобства, но по принципу действия он не сильно уходить от npm run : каждая команда вызывается отдельно, что значительно замедляет весь процесс.

Быстрые npm-скрипты

Redrun

Что может redrun?

Взаимодействие

Установим tape для тестов, и запишем простейший тест, который проходит.

Теперь в секцию scripts файла package.json добавим несколько разделов:

После чего запустим тест с помощью npm :

А теперь то же самое, только с помощью redrun :

Даже на таком простом примере видно, что скорость выполнения почти в 3 раза выше.

Теперь попробуем тоже самое со скриптом npm watch:test :

Попробуем тоже-самое выполнить с помощью npm :

С помощью npm нам потребовалось 11 секунд, для того, что бы узнать, что nodemon не установлен.

Теперь все работает: запускается наблюдатель, который смотрит за изменениями в папках test и lib и перезапускает tape test.js — именно то, что нам нужно. При этом остается возможность использовать компактный синтаксис скриптов в package.json.

Процесс разработки

Redrun пишется по TDD, по этому вносить изменения: добавлять фичи, или фиксить баги — очень просто. Если читатель заметит не очевидное и не документированное расхождение в работе redrun по сравнению с аналогичными инструментами: создавайте ишью, присылайте пул реквесты — будем исправлять.

Источник

Продукты и технологии:

Visual Studio 2015, Grunt, Gulp, Node.js, ASP.NET 5

В статье рассматриваются:

Что выбрать — Grunt или Gulp?

Выбор средства запуска задач (task runner) обычно зависит от личных предпочтений или специфики проекта, если только вы не используете плагин, поддерживающий лишь конкретное средство запуска задач. Основные отличия в том, что Grunt управляется конфигурационными параметрами в формате JSON и каждая задача Grunt, как правило, должна создавать промежуточные файлы для передачи чего-либо в другие задачи, тогда как Gulp управляется исполняемым JavaScript-кодом (т. е. не только JSON) и может направлять результаты от одной задачи следующей без использования временных файлов. Gulp является более новым инструментом и, как таковой, часто используется в более новых проектах. Тем не менее, Grunt имеет множество общеизвестных средств поддержки, например jQuery, который использует его для создания… jQuery. И Grunt, и Gulp работают через плагины — модули, которые вы устанавливаете для обработки конкретной задачи. Существует огромная экосистема плагинов, и часто встречаются пакеты задач, поддерживающие как Grunt, так и Gulp, поэтому использование одного или другого средства вновь сводится, по сути, к персональному выбору.

Установка и использование Grunt

Установщиком для Grunt и Gulp является Node Package Manager (npm), о котором я кратко рассказал в своей статье за октябрь 2015 года (msdn.com/magazine/mt573714). Команда установки Grunt на самом деле состоит из двух частей. Первая — это разовая установка интерфейса командной строки Grunt, а вторая — установка Grunt в папку вашего проекта. Такая установка из двух частей позволяет использовать несколько версий Grunt в системе и применять интерфейс командной строки Grunt по любому пути:

Конфигурация Grunt

1 Под этим термином подразумевается сокращение кода. — Прим. ред.

Конфигурационный файл Grunt — это просто JavaScript-файл с функцией-оболочкой, содержащей конфигурацию, список загружаемых плагинов и определение задачи (рис. 1).

Рис. 1. Конфигурационный файл Grunt

Вы можете запускать задачи на рис. 1 в командной строке простым вызовом:

После этого вызова вы найдете минимизированный (uglified, или minified) и объединенный результат в wwwroot/output-min.js. Если вы пользовались минимизацией и объединением (bundling) в ASP.NET, то заметите, что этот процесс отличается: он не привязан к запуску вашего приложения или даже к компиляции, и существует намного больше вариантов, которые вы можете выбирать для задач вроде минимизации (uglifying). Лично я нахожу этот рабочий процесс более прямолинейным и понятным.

Задачи можно объединять в цепочки с помощью Grunt так, чтобы они зависели друг от друга. Эти задачи будут выполняться синхронно, так как сначала должна быть выполнена первая задача и только потом можно переходить к следующей:

Установка и использование Gulp

Установка Gulp аналогична установке Grunt. Я расскажу о Gulp немного подробнее, но заметьте, что вы можете делать похожие вещи с помощью любого из инструментов; я просто не хочу слишком часто повторяться. Gulp можно устанавливать глобально (чтобы использовать по любому пути в системе) и локально в папку проекта (чтобы использовать в конкретном проекте конкретную версию). Глобально установленный Gulp будет передавать управление тому, который был установлен локально в ваш проект, если найдет его, тем самым сохраняя версию Gulp в проекте:

Конфигурация Gulp и API

Конфигурация Gulp значительно отличается от таковой для Grunt. Конфигурационный файл gulpfile.js, который обычно имеет структуру, показанную на рис. 2, содержит выражения require для загрузки плагинов и последующего определения задач. Заметьте, что здесь я не использую конфигурационные параметры JSON; вместо этого задачи управляются кодом.

Конфигурационный файл Grunt — это просто JavaScript-файл с функцией-оболочкой, содержащей конфигурацию, список загружаемых плагинов и определение задачи.

Рис. 2. Конфигурационный файл Gulp

Gulp работает, используя несколько ключевых API и концепций: src, dest, pipe, task и globs. Gulp.src API сообщает Gulp, какие файлы следует открыть для работы, и эти файлы потом, как правило, отправляются по конвейеру какой-то другой функции вместо создания временных файлов. Это главное отличие от Grunt. Ниже показано несколько базовых примеров gulp.src без конвейеризации результатов, о которой я расскажу позже. Этот API-вызов принимает glob как параметр. Glob — это, по сути, шаблон (нечто вроде регулярного выражения), который вы можете ввести, чтобы, например, указать путь к одному или более файлам (подробнее о globs см. в github.com/isaacs/node-glob):

Dest (destination) API, как можно представить себе, указывает получателя (destination) и также принимает glob. Поскольку globs очень гибки для определения путей, вы можете осуществлять вывод либо в индивидуальные файлы, либо в папку:

Задачи в Gulp — это просто код, который вы пишете для выполнения каких-либо операций. Формат задач весьма несложен, но задачи можно использовать несколькими способами. Самый прямолинейный способ — создание задачи по умолчанию и одной или более других задач:

Visual Studio обеспечивает поддержку Gulp и Grunt через Task Runner Explorer, который включен в Visual Studio 2015 и доступен как Visual Studio Extension.

Задачи могут выполняться параллельно или могут быть зависимы друг от друга. Если порядок выполнения задач не важен, их можно просто объединить в цепочку, например:

В этом примере определяется задача по умолчанию, которая ничего не делает, но запускает отдельные задачи для конкатенации JavaScript-файлов и компиляции файлов LESS (предполагая, что код был в задачах, перечисленных здесь). Если требования диктуют завершение одной задачи до выполнения другой, вам нужно сделать задачи зависимыми друг от друга, а затем запустить несколько задач. В следующем коде задача по умолчанию сначала ожидает завершения concat, которая в свою очередь ожидает завершения uglify:

Pipe API используется для конвейерной передачи результатов от одной функции другой, используя stream API из Node.js. Рабочий процесс обычно таков: чтение src, конвейеризация в task, а потом конвейеризация результатов в dest. Следующий полный пример gulpfile.js считывает все JavaScript-файлы в /scripts, соединяет их в один файл и записывает вывод в другую папку:

Возьмем практический пример. Вам будет часто требоваться объединять файлы и/или добавлять дополнительные заголовки в файлы исходного кода. Это можно легко делать в несколько этапов, добавив пару файлов в корень вашего веб-сайта (то же самое можно сделать в коде — см. документацию на gulp-header). Сначала создайте файл copyright.txt, содержащий добавляемые заголовки:

Затем создайте файл version.txt, содержащий номер текущей версии (существуют плагины вроде gulp-bump и grunt-bump, которые увеличивают номера версий):

Теперь установите плагины gulp-header и gulp-concat в корень своего проекта:

В качестве альтернативы можно вручную добавить их в файл package.json и позволить Visual Studio выполнить восстановление пакетов за вас.

Наконец, вам нужен файл gulpfile.js, чтобы сообщить Gulp, что именно делать, как показано на рис. 3. Если вы не хотите объединять все свои скрипты и вместо этого предпочитаете просто добавить заголовки в каждый файл, закомментируйте строку pipe(concat). Ничего сложного, правда?

Task Runner Explorer

Visual Studio обеспечивает поддержку Gulp и Grunt через Task Runner Explorer, который включен в Visual Studio 2015 и доступен как Visual Studio Extension. Вы найдете его в View | Other Windows | Task Runner Explorer. Task Runner Explorer весьма впечатляет, так как он распознает, есть ли в вашем проекте gulpfile.js или gruntfile.js, разбирает задачи и предоставляет UI для выполнения найденных задач (рис. 4). Более того, вы можете определять задачи для запуска, когда в вашем проекте происходят заранее определенные операции, о чем я расскажу далее, поскольку ASP.NET 5 использует эту функциональность в своих шаблонах по умолчанию. Просто щелкните правой кнопкой мыши задачу, чтобы выполнить ее или связать с определенной операцией, например для запуска при открытии проекта.

Шаблоны ASP.NET 5, включенные в Visual Studio 2015, используют Gulp, и они устанавливают Gulp в папку node_components вашего проекта, так что все это будет заранее готово для применения в проекте.

Рис. 4. Task Runner Explorer показывает задачи Grunt и Gulp с параметрами

Как иллюстрирует рис. 5, Grunt выводит параметры, когда вы выбираете какую-либо задачу Grunt, которую вы не увидите в случае Gulp, в частности параметры Force, чтобы игнорировать предупреждения, и Verbose (буквы «F» и «V» слева вверху). Это просто параметры, передаваемые в командную строку Grunt. Замечательное качество Task Runner Explorer в том, что он показывает команды, передаваемые им в командную строку Grunt или Gulp (в окне вывода задачи), поэтому вам не придется гадать, что происходит «за кулисами».

Рис. 5. Дополнительные команды Grunt и командная строка

Gulp и ASP.NET 5

Шаблоны ASP.NET 5, включенные в Visual Studio 2015, используют Gulp, и они устанавливают Gulp в папку node_components вашего проекта, так что все это будет заранее готово для применения в проекте. Конечно, вы можете по-прежнему пользоваться Grunt в проекте ASP.NET 5; просто вам придется установить его в проект с помощью npm или добавлением в packages.json в раздел devDependencies с последующим автоматическим восстановлением пакетов в Visual Studio. Хочу подчеркнуть: все это делается в командной строке или в самой Visual Studio — выбор за вами.

Рис. 6. Готовые задачи в шаблонах предварительной версии ASP.NET 5

Следующая строка в gruntfile.js демонстрирует другой пример одновременного запуска нескольких задач:

У вас есть возможность связывать задачи Grunt и Gulp с четырьмя разными действиями в Visual Studio. В случае MSBuild для выполнения различных задач часто определяли командную строку для обработки перед компиляцией и после нее. При использовании Task Runner Explorer вы можете определить события Before Build, After Build, Clean и Project Open, чтобы выполнять такие задачи. При этом в файл gulpfile.js или gruntfile.js просто добавляются комментарии, которые не влияют на выполнение, но распознаются Task Runner Explorer. Чтобы увидеть привязку clean в gulpfile.js из ASP.NET 5, взгляните на следующую строку в начале этого файла:

И это все, что требуется для подключения события.

Заключение

Grunt и Gulp — отличное пополнение в вашем арсенале средств веб-разработки. Оба инструмента прекрасно поддерживаются и имеют колоссальную экосистему плагинов. Любой веб-проект может выиграть от того, что они предлагают. За более подробной информацией обратитесь к следующим ресурсам:

Адам Тьюлипер (Adam Tuliper) — старший идеолог Microsoft, живет в солнечной Калифорнии. Занимается веб-разработкой, созданием игр, является автором на Pluralsight и интересуется разнообразной техникой. С ним можно связаться через Twitter (@AdamTuliper) или через блог Adam’s Garage (bit.ly/1NSAYxK).

Выражаю благодарность за рецензирование статьи эксперту Microsoft Майклу Палермо (Michael Palermo).

Источник

Зачем нужны таск менеджеры GULP и GRUNT?

Оценить 6 комментариев

Мне кажется тут не хватает образного примера:

Вот и сказочке конец, а кто слушал, тот и gulp.

Сейчас же, весь этот «девелоперский» антураж в виде фреймворков для фреймворков для запуска фреймворков с кучей json конфигов, с пафосным названием и флэт логотипом : )

Просто я реально не понимаю сути этих всех прелестных менеджеров!

Сказали ведь, автоматизация )
Я по началу тоже задавался этим вопросом.

Скажем так, если ты пишешь на Jade или другом шаблонизаторе + CSS препроцессор + CoffeeScript и проект разделен на множество файлов (модульность), то в таком случае это очень удобно, все это собирается буквально одной строчкой в консоле.
Плюс к этому добавь дополнительные плюшки в виде оптимизации изображений на лету, добавление актуальных префиксов и т.д.
А если еще и Bower(менеджер пакетов) прикрутить, то вообще лепота.

Использовать эти инструменты для какой-то одной или двух из этих задач конечно глупо.

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

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

А через три дня в команду взяли Васю, который пишет только на виме, что теперь делать?

А что делать с деплоем, как получить на проде склеенные скрипты и CSS из LESS? Cтавить на сервер сублайм? Так там даже иксов нет. Хранить в гите артефакты сборки? Плохая идея (каюсь, я пробовал).

Источник

Перевод Task runner #194

Comments

lahmatiy commented Aug 1, 2015

В который раз не знаю как это правильно назвать по-русски, то есть инструменты вроде Grunt, Gulp, Webpack etc.
Как лучше называть такие инструменты?

The text was updated successfully, but these errors were encountered:

pepelsbey commented Aug 1, 2015

Gulp называет себя «build system», поэтому и я предпочитаю называть это «системы сборки» — чем они, по сути, и являются в большинстве случаев.

tachisis commented Aug 6, 2015

«Сборщик» или «система сборки», да.

lahmatiy commented Aug 6, 2015

@pepelsbey @tachisis Ребята, я вас умоляю. следуя вашей логике, любой bash-скрипт это сборщик. Сборка это одна из задач решаемых такими инструментами (вернее позволяющих ее решить), но они далеко этим не ограничены.
Речь про инструменты позволяющие (упрощающие) автоматизацию задач. Собственно задачи описываем мы (по шагам), подобные инструменты их исполняют. Не сужайте определение, пожалуйста.

pepelsbey commented Aug 6, 2015

Рома, мы ничего не сужаем. Мы сейчас говорим о том явлении, которое на слуху и в практике. Упомянутые Grunt, Gulp и Webpack сейчас используются в подавляющем большинстве случаев именно как сборщики.

Так о чём мы сейчас, о каком явлении?

lahmatiy commented Aug 7, 2015

О более широком термине – Task Runner, как класс инструментов/программ.

marinintim commented Aug 18, 2015

На хабре вижу два варианта:

Менеджер явно мимо кассы, а исполнитель слишком абстрактно. Но и сам термин task runner тоже, этак и мои две строчки на баше будут зваться таскраннером.

talgautb commented Nov 17, 2015

тоже думал как перевести именно task runner, ничего не придумал 🙁

skinet2009 commented Dec 21, 2017 •

Инструмент/система управления задачами/проектами.

Источник