Таск раннеры существенно упростили жизнь веб разработчиками автоматизируя рутинные действия связанные с запуском тестов, проверкой кода, объединением в один файл, транспайлингом и прочими не менее полезными делами. Опустим вопрос необходимости подобных инструментов, конечно, можно и без них, но они существенно упрощают жизнь и делают более качественным процесс разработки.
Все пользуются таск раннерами в той или иной мере: кто-то старинным грантом, кто-то постепенно уходящим с арены галпом и многими другими, а кто-то уже во всю использует npm-скрипты.
Последние мы сегодня разберем во всех деталях, а так же способы их ускорения и расширения возможностей
Причины использовать npm как таск раннер
Написанное ниже является субъективным опытом, и на истину последней инстанции не претендует, тем-не-менее является важными причинами дальнейшего повествования.
По мере появления перечисленных выше таск раннеров, они были мной испробованы в бою, и в каждом из них (конечно же) есть плюсы, и минусы. Рассмотрим их вкратце.
У гранта низкий порог вхождения, благодаря конфигам, которые в тот же момент являются его краеугольным камнем, заставляя генерировать их программно, из-за большого количества передаваемых полей. Галп решает эту проблему целиком, добавляя минимализм и скорость выполнения, благодаря стримам, что повышает порог вхождения, требуя от пользователей понимания того, как все работает изнутри.
И так, отойдя от гранта, разобравшись со стримами и написав лаконичный Gulpfile я успокоился и продолжил разработку текущего проекта. Для следующего приложения, я, конечно, снова написал Gulpfile. И для следующих. И для многих других.
После чего сам gulp, и его плагины начали обновляться, а потом и его зависимости, которые бывало нужно было обновлять самостоятельно. Конечно можно не использовать сервисы, следящие за обновлениями пакетов, устранением уязвимостей, исправлением ошибок и всем прочим, но это не самый хороший подход к разработке.
Таким образом мы подошли к главному недостатку большинства такс раннеров: их нужно обновлять, их зависимости нужно обновлять и зависимость зависимостей тоже. Для монолитных приложений это не представляет проблемы. Проблемы начинаются тогда, когда частей приложения много, и каждая из них является независимым модулем, а это ли не основная парадигма разработки на node.js?
Итак, вместо того, что бы обновлять: gulp, gulp-jshint и jshint, я лучше просто буду использовать jshint напрямую, с помощью интерфейса командной строки, который не часто меняется, значительно упрощая себе этим жизнь.
Конечно у такого подхода есть и минусы, куда же без них? Если беспорядочно пихать все подряд в секцию scripts файла package.json, очень скоро там черт ногу сломит. По этому следует использовать короткие команды четко отражая их поведение в названии.
npm-скрипты
Когда я начал активно использовать npm-скрипты, я, как и многие разработчики, осознал неудобство и многословность такого подхода, к примеру, если нужно организовать проверку линтерами, код будет выглядеть таким образом:
{ "lint:jshint": "jshint lib test", "lint:eslint": "eslint lib test", "lint:jscs": "jscs lib test" }
Тогда скрипт, который запускает все проверки будет выглядит так:
{ "lint": "npm run lint:jshint && npm run lint:eslint && npm run lint:jscs" }
Очень уж многословно, а тут всего-то 3 скрипта запускаются.
Удобные npm-скрипты
Есть много библиотек, упрощающих взаимодействие с npm-скриптами. Мы рассмотрим одну главную, которая объединяет функционал всех существующих решений, и в то же время, не отходит от основной парадигмы: запуск скриптов средствами npm.
npm-run-all
Предыдущий пример получился очень многословным (гораздо более коротким чем в случае с грантом и галпом, но тем-не-менее) и сложночитаемым. npm-run-all существенно все упрощает. С его помощью, код делающий тоже самое будет выглядеть так:
{ "lint": "npm-run-all lint:jshint lint:eslint lint:jscs" }
(npm-run-all можно смело заменять на более короткое название: run-s, крайние версии npm-run-all это поддерживают)
И делать примерно то же самое: поочередно запускать скрипты.
npm-run-all очень не плохо себя показывает в плане удобства, но по принципу действия он не сильно уходить от npm run: каждая команда вызывается отдельно, что значительно замедляет весь процесс.
Быстрые npm-скрипты
Я долгое время использовал npm-run-all, но в какой-то момент осознал, что запуск скриптов может быть более оптимальным, быстрым и при этом обладать простой реализацией. Первые результаты показали себя очень хорошо в плане скорости и эффективности, при этом не теряя в удобстве.
Redrun
Принцип действия redrun значительно отличается от аналогов: вместо того, что бы запускать каждую команду отдельно, он объединяет все вложенные команды в одну большую, и уже ее передает на выполнение системному шеллу. Благодаря такой оптимизации, скорость выполнения npm-скриптов существенно возрастает, при этом остается возможность запуска скриптов параллельно и последовательно. Пример со скриптом lint, после парсинга будет выглядеть таким образом:
jshint lib test && jscs lib test && eslint lib test
Что может redrun?
Кроме возможности запуска скриптов последовательно, параллельно, а так же в смешанном режиме, redrun парсит все вхождения скриптов, начинающиеся с npm run, а так же npm test (включая префиксные и постфиксные скрипты), оставляет возможность использования с��кции конфигов в package.json, а еще парсит все вхождения redrun, которыми могут запускаться скрипты, что делает его уникальным инструментом для написания лаконичных и понятных скриптов, ибо в конечном счете все превратится в одну большую команду. Стоит еще отметить совместимость большей части функционала с рассмотренным выше npm-run-all, а так же npm (той его части, которая касается непосредственно запуска скриптов).
Взаимодействие
Рассмотрим пример использования redrun. Для начала установка (ничего особенного):
$ npm i redrun -g
Дальше создаем package.json с помощью npm init -y:
$ mkdir example $ cd example $ npm init -y Wrote to /home/coderaiser/example/package.json: { "name": "example", "version": "1.0.0", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "coderaiser" "license": "MIT", "description": "" }
Установим tape для тестов, и запишем простейший тест, который проходит.
$ npm i tape -D $ cat > test.js 'use strict'; const test = require('tape'); test('some test', (t) => { t.pass(); t.end(); }); ^C
Теперь в секцию scripts файла package.json добавим несколько разделов:
{ "test": "tape test.js", "watch:test": "npm run watcher -- npm test", "watcher": "nodemon -w test -w lib --exec" }
После чего запустим тест с помощью npm:
$ time npm test reel 0m6.617s user 0m1.262s sys 0m1.778s
А теперь то же самое, только с помощью redrun:
$ time redrun test real 0m2.389s user 0m0.495s sys 0m0.544s
Даже на таком простом примере видно, что скорость выполнения почти в 3 раза выше.
Теперь попробуем тоже самое со скриптом npm watch:test:
$ time redrun watch:test > nodemon -w test -w lib --exec tape test.js /bin/sh: 1: nodemon: not found Command failed: nodemon -w test -w lib --exec tape test.js real 0m1.211s user 0m0.208s sys 0m0.332s
Ага, nodemon мы не установили, и нам потребовалась всего 1 секунда, что бы это узнать. Хочу обратить внимания читателя, на то, что команда полностью развернулась, и nodemon (после установки) будет перезапускать непосредственно tape, а не npm test.
Попробуем тоже-самое выполнить с помощью npm:
$ time npm run watch:test > article@1.0.0 watch:test /home/coderaiser/article > npm run watcher -- npm test > article@1.0.0 watcher /home/coderaiser/article > nodemon -w test -w lib --exec "npm" "test" sh: 1: nodemon: not found npm ERR! syscall spawn npm ERR! spawn ENOENT npm ERR! article@1.0.0 watch:test: `npm run watcher -- npm test` npm ERR! Exit status 1 real 0m11.594s user 0m2.181s sys 0m2.849s
С помощью npm нам потребовалось 11 секунд, для того, что бы узнать, что nodemon не установлен.
Установим nodemon:
$ npm i nodemon -D
Попробуем снова:
$ redrun watch:test > nodemon -w test -w lib --exec tape test.js [nodemon] 1.10.2 [nodemon] to restart at any time, enter `rs` [nodemon] watching: test lib [nodemon] starting `tape test.js` TAP version 13 # some test ok 1 (unnamed assert) 1..1 # tests 1 # pass 1 # ok [nodemon] clean exit - waiting for changes before restart
Теперь все работает: запускается наблюдатель, который смотрит за изменениями в папках test и lib и перезапускает tape test.js — именно то, что нам нужно. При этом остается возможность использовать компактный синтаксис скриптов в package.json.
Процесс разработки
Redrun пишется по TDD, по этому вносить изменения: добавлять фичи, или фиксить баги — очень просто. Если читатель заметит не очевидное и не документированное расхождение в работе redrun по сравнению с аналогичными инструментами: создавайте ишью, присылайте пул реквесты — будем исправлять.
Вывод
npm хороший инструмент, который исправно выполняет то, для чего предназначен. Экосистема node.js очень стремительно эволюционирует и не последнее место в этом процессе отыгрывает npm (а одно из первых). Я думаю, придет момент, когда redrun станет не нужен в силу того, что npm и так все быстро будет делать. Но пока этот момент не настал, и для того, что бы его приблизить, создан помощник npm в таком непростом, но важном деле как запуск скриптов.
