Я почав використовувати скрипти npm в своїх проектах приблизно півроку назад. До цього я використовував Gulp. а ще раніше Grunt. Вони відмінно працювали і допомагали мені швидше справлятися зі своєю роботою, ефективно автоматизуючи багато речей, які до цього доводилося робити вручну. Однак я почав помічати, що витрачаю на настройку цих інструментів більше часу, ніж на сам код.
Grunt, Gulp, Broccoli, Brunch і подібні інструменти змушують вас підлаштовувати ваші завдання під їх парадигми і конфігурації. У кожного інструменту свій власний синтаксис, свої глюки і заморочки, які вам доводиться вивчати. Це додає складності коду і процесу складання, змушує вас фокусуватися на налагодженні, а не написання коду.
Ці інструменти збірки залежать від плагінів, які є обгортками для інструментів командного рядка. Це додає ще один рівень абстракції, що збільшує ймовірність проблем.
Три проблеми, з якими я багато разів стикався
- Якщо у вашій системі збірки немає плагіна для потрібного вам інструменту командного рядка - можете вважати, що вам не пощастило. Або написати такий плагін самостійно.
- Плагін, який ви намагаєтеся використовувати, є обгорткою для старої версії потрібного вам інструменту. Функціонал і документація у інструменту і відповідного йому плагіна з системи збірки не завжди збігаються.
- Помилки не завжди обробляються так, як треба. Плагін при помилку може не передати нічого системі збірці, приводячи вас в фрустрацію без розуміння шляхів вирішення проблеми.
Невелике уточнення
Дозвольте мені сказати це: якщо вас влаштовує звична вам система збирання і вона вирішує всі ваші завдання, продовжуйте використовувати її! Те, що скрипти npm стають дедалі популярнішими, не означає, що вам терміново потрібно переходити на них. Фокусуйтеся на написанні коду, а не на освоєнні інструментів. Якщо у вас з'являється відчуття, що ви боретеся зі своїми інструментами, тоді вам варто подумати про використання скриптів npm.
Написання скриптів npm
Велику частину часу ми будемо витрачати на файл package.json. Саме в ньому живуть усі залежності і скрипти. Ось кілька урізана версія з мого шаблонного проекту:
Ми будемо розширювати наш package.json у міру потреби. Наші скрипти будуть додаватися в об'єкт scripts. а всі необхідні інструменти будуть інсталюватися і поміщатися в об'єкт devDependencies.
Перед тим як перейти до справи, поглянемо на структуру нашого проекту, на неї ми будемо посилатися по ходу поста.
Компіляція SCSS в CSS
Я активно використовую SCSS, так що без нього мені не обійтися. Щоб скомпілювати SCSS в CSS я використовую node-sass. Для початку треба встановити node-sass. це робиться в командному рядку:
Команда встановить node-sass в ваш поточний каталог, а також додасть в об'єкт devDependencies в package.json. Це особливо корисно, коли будь-хто інший запускає ваш проект - у нього вже є все для роботи проекту. Після інсталяції ми можемо компілювати SCSS за допомогою команди:
Розберемо, що робить ця команда. Прапор --output-style відповідає за вид скомпільованих стилів, у нас він в значенні в значенні compressed - стилі стискаються; скомпільовані файли виводяться в каталог dist / css. це прапор -o; в каталозі src / scss йде пошук на предмет наявності файлів SCSS, які ми будемо компілювати.
Тепер, коли ми розібралися, як це працює в командному рядку, повернемося до нашого скрипту npm. Додайте цю команду в об'єкт scripts вашого файлу package.json. приблизно так:
Поверніться в командний рядок і виконайте:
Ви побачите точно такий же результат, як і при безпосередньому виконанні node-sass.
Будь-скрипт npm з цього поста можна виконати за допомогою подібної команди.
Просто замініть scss на назву завдання, яку ви хочете виконати.
Як бачите, у багатьох інструментів командного рядка, які ми будемо використовувати, є численні опції, які ми можемо налаштовувати під себе. Ось, наприклад, список опцій для node-sass. Ось зразок конфігурації з передачею безлічі опцій:
Автопрефіксер
Після компіляції Scss в CSS ми можемо автоматично додати Вендорний префікси, використовуючи Autoprefixer PostCSS. Ми відразу встановимо кілька модулів, розділивши їх пробілами:
Ми встановлюємо два модуля, тому як сам по собі PostCSS нічого не робить. Він потребує інших плагінах типу Autoprefixer, щоб маніпулювати переданим CSS.
Після установки і збереження в devDependencies всіх необхідних інструментів, додайте завдання в об'єкт scripts.
Це завдання свідчить: "Ей, postcss, використовуй (use, прапор -u) autoprefixer з заміною всіх старих файлів в каталозі dist / css на нові, з Вендорний префіксами". Усе! Потрібно поміняти набір підтримуваних браузерів для автопрефіксера? Змініть його конфігурацію:
Знову-таки, це далеко не всі доступні опції, які ви можете використовувати у своїй збірці, ось списки опцій для postcss-cli і для autoprefixer.
Знову, почнемо з установки пакета, в цей раз короткої:
По дії ця команда ідентична традиційної:
Після установки, ми налаштуємо деякі базові правила для перевірки нашого коду за допомогою eslint. Виконайте наступну команду для запуску майстра настройки:
Я пропоную вибрати варіант "Answer questions about your style" і відповісти на всі питання. В результаті в корені вашого проекту буде згенеровано файл з настройками eslint для лінтінга вашого коду.
Тепер додамо завдання в об'єкт scripts нашого файлу package.json:
Потім налаштуємо завдання по мініфікаціі в package.json:
Однією з сильних сторін скриптів npm є те, що вони за своєю суттю є псевдонімами для задач в командному рядку, які ви хочете запускати неодноразово. Це означає, що ви можете використовувати стандартний код командного рядка безпосередньо в своєму скрипті! Наше завдання використовує дві можливості стандартної командного рядка, це mkdir і .
Перша частина завдання (mkdir -p dist / js) говорить: "створи каталог (mkdir), але тільки якщо він ще не існує (прапор -p)". Після успішного виконання цієї команди, запускається друга частина завдання, безпосередньо мініфікація (uglifyjs). оператор з'єднує ці дві команди в послідовність, дозволяючи запуск другої тільки після успішного виконання першої.
Давайте відновимо завдання uglify для створення стислій версії dist / js / app.js. Додамо ще одну команду uglifyjs. передавши їй прапор "compress" (-c):
стиснення зображень
Imagemin хороший тим, що стискає більшість типів зображень, включаючи GIF, JPG, PNG і SVG. Ви можете передати йому каталог з зображеннями, решту він зробить сам:
Це завдання змушує imagemin знайти і стиснути все зображення в каталозі src / images. помістивши стислі зображення в каталог dist / images. Прапор -p (progressive) означає прогресивне стиснення зображень, коли це можливо. У документації описані всі доступні опції.
SVG спрайт
Галас навколо SVG посилилася за останні кілька років і для цього є хороша причина. Зображення SVG чіткі на всіх пристроях, редагуються за допомогою CSS і добре працюють зі скрінрідерамі. Однак програмне забезпечення для створення SVG зазвичай залишає багато стороннього і непотрібного коду. На щастя, svgo допомагає позбутися від сміття (ми встановимо svgo трохи пізніше, разом з іншим пакетом).
Ви можете автоматизувати процес комбінування і створення спрайтів з SVG для отримання одного файлу SVG (докладніше ця техніка описана в статті на css-tricks.com). Для автоматизації процесу ми встановимо svg-sprite-generator.
Послідовність дій вже повинна бути знайома вам: після установки ми додамо завдання в об'єкт scripts в файлі package.json:
Зверніть увагу, що завдання icons робить три речі, завдяки наявності двох операторів . По-перше, ми використовуємо svgo передається каталог (прапор -f. Folder) з SVG, які svgo стискає. По-друге, за допомогою команди mkdir -p ми створюємо каталог dist / images. якщо він до цих пір не створено. І по-третє, ми використовуємо svg-sprite-generator. передаючи йому каталог з вихідними кодами (прапор -f. folder) і вказавши каталог-призначення (прапор -o. output) для готового спрайту.
Локальний сервер і автоматичне застосування змін з BrowserSync
Один з останніх фрагментів нашого пазла це BrowserSync. Він може робити кілька речей: запускати локальний сервер, автоматично оновлювати файли в будь-якому підключеному браузері і синхронізувати кліки та прокрутку між браузерами. Встановіть його і додайте завдання:
Наше завдання BrowserSync запускає сервер (прапор --server), використовуючи в якості кореневого для сервера поточний каталог. Прапор --files задає шлях до відслідковується файлів CSS або JS в каталозі dist. коли щось в цьому каталозі змінюється, зміни автоматично вставляються на сторінку.
Ви можете відкрити кілька браузерів (навіть на декількох пристроях) і вони будуть отримувати оновлення файлів в режимі реального часу.
групування завдань
Додавши всі перераховані завдання, ми можемо робити наступне:
Але ми не будемо зупинятися на цьому.
Об'єднання завдань CSS
Додамо завдання, що поєднує два завдання, пов'язані з CSS (обробка Sass і запуск автопрефіксера), щоб нам не доводилося запускати їх окремо:
Коли ви виконуєте npm run build: css. в командному рядку виконується npm run scss. після успішного виконання цієї команди оператор запускає виконання другої команди: npm run autoprefixer.
Об'єднання інших завдань
Ми можемо об'єднати всі завдання, пов'язані з зображеннями, а також зробити одну універсальну завдання, що об'єднує всі попередні:
відстеження змін
До цієї точки всі наші завдання вимагали внесення змін до файл, перемикання назад в командний рядок і запуску відповідного завдання. Одна з найбільш корисних речей, які ми можемо зробити, це відстеження змін в файлах з відповідним автоматичним запуском завдань. Для того, щоб зробити це я рекомендую використовувати onchange. Встановлюємо як зазвичай:
Ось розбір основних моментів: onchange приймає каталог, який потрібно відстежувати. У нашому випадку це файли SCSS і JS. Після двох дефісів (-) вказується команда, яка буде виконуватися при будь-якому додаванні, зміну або видалення файлів у відповідному відстежувати каталозі.
Остаточний вигляд процесу складання за допомогою скриптів npm
Встановимо ще один пакет parallelshell:
Як завжди, додамо нову задачу в об'єкт scripts:
parallelshell приймає в якості аргументів кілька рядків з командами, які виконує при запуску npm run.
Чому ми використовуємо parallelshell для об'єднання множинних завдань, а не оператор . як в попередніх випадках. Я намагався. Проблема в тому що пов'язує команди разом і чекає успішного закінчення кожної з них перед тим, як запускати наступну. Однак, так як у нас в ланцюжку є команда watch. завершення не буде - ми застрянемо в нескінченному циклі.
Тому використання parallelshell дозволяє нам одночасно виконувати кілька завдань watch. Подібним функціоналом володіє також npm-run-all.
Інші корисні команди
npm може вирішувати безліч завдань. Додамо ще одну задачу до наших складальним скриптів.
postinstall запускається відразу після виконання npm install в командному рядку. Особливо гостро це для роботи в команді: коли хто-небудь клонує ваш проект і виконує npm install. завдання в watch: all стартують негайно, тобто запускається сервер і відкривається вікно браузера, в якому відстежуються всі зміни файлів.
висновок
Так, ми зробили це! Сподіваюся, що ви вивчили деякі основи використання npm-скриптів для процесу складання і роботи командного рядка в цілому.
На випадок, якщо ви щось упустили, я створив npm-build-boilerplate. в якому є всі згадані завдання і який можна використовувати в якості стартової точки.