Angular CLI поза межами ng serve: генератори, цілі, кеш та статистика збірки

Більшість розробників Angular на початковому етапі опановують чотири команди — ng serve, ng build, ng generate та ng test — і більше не шукають іншого. Це підходить для невеликих додатків, але коли простір роботи збільшується, час, витрачений на ручне створення шаблонів, пошук версійних номерів, оцінку розміру пакету та виправлення пошкоджених кешів, значно зростає. CLI вже містить рішення для більшості цих завдань. У цьому посібнику розглядаються опції, які варто зробити звичними, пояснюється, коли кожна з них корисна, та наводиться компактний щоденний робочий процес, який можна використовувати без змін.

Якщо ви ще на етапі створення самого простору роботи, інструкція з створення сучасного проекту Angular охоплює цю частину; усе, що йде далі, передбачає наявність вже створеного проекту.

Отримайте більше вигоди від ng generate

Генератор – це команда, яку всі знають у своїй повній формі:

ng generate component user-profile

Кожен генератор має короткий псевдонім, тож generate стає g, а component – c:

ng g c user-profile

Справжня економія досягається завдяки флагам. Коли невеликий презентаційний компонент не потребує файлу специфікації, --skip-tests заважає CLI створювати його:

ng g c user-profile --skip-tests

За замовчуванням кожен компонент зберігається у власній папці. --flat замість цього записує файли безпосередньо у поточну директорію, що підходить для маленьких компонентів, які знаходяться поруч із своїм батьківським файлом:

ng g c user-profile --flat

Флаги можна поєднувати, тож ви можете запросити їх обидва одночасно:

ng g c user-profile --flat --skip-tests

Ті самі опції застосовуються до сервісів, директив, трубок, захисників та інших схем. Дозвіл генератору створювати файли забезпечує послідовність найменувань та форматування в усій команді. Додайте --dry-run, щоб попередньо переглянути, що створить схема, не записуючи нічого.

Запитайте CLI замість пошуку в Інтернеті

Найшвидший спосіб дізнатися, що може робити генератор, — це запитати його. Це перелічує всі доступні схеми:

ng generate --help

Псевдонім працює так само:

ng g --help

Додавання --help після конкретної схеми виводить усі її опції з короткими описами:

ng g component --help

Опції змінюються між версіями, а відповіді на форумах часто описують старі прапорці; вивід допомоги завжди відповідає CLI, встановленому у вашому проекті.

Читайте та змінюйте налаштування за допомогою ng config

Конфігурація робочого простору знаходиться у файлі angular.json, і буває спокуса змінювати цей файл безпосередньо. CLI пропонує команду для читання та запису цих значень:

ng config

Якщо її викликати окремо, вона виведе конфігурацію, щоб ви могли побачити, що налаштовано:

ng config

Ви також можете передати шлях до JSON для читання певного значення або шлях разом із значенням для його зміни, наприклад, щоб змінити параметр CLI для всього робочого простору. У скриптах краще використовувати повторюваний виклик ng config, ніж робити крихкі ручні зміни в JSON: якщо файл контролюється CLI, використовуйте CLI для його зміни.

Звітуйте про своє середовище за допомогою версії ng

Коли щось ламається, важливі точні версії. Замість того, щоб відкривати package.json та самостійно все збирати, виконайте:

ng version

або його скорочену форму:

ng v

У результаті виводиться версія Angular CLI, встановлені пакети Angular, Node.js, менеджер пакетів та операційна система в одному блоку. Саме цього потребують колега чи адміністратор, коли ви просите про допомогу. Звіт, який лише повідомляє про те, що проект перестав працювати, не дає їм жодних підказок, тоді як копіювання результату виконання наступної команди відповідає на їхні перші п’ять запитань відразу:

ng version

Вимірюйте розмір бандлу для продакшну замість того, щоб здогадуватися

Цей флаг для збірки заслуговує на значно більше використання, ніж має зараз:

ng build --stats-json

Він створює файл зі статистикою, який описує склад кожного частини вихідного коду. Передайте цей файл у аналізатор пакетів, і ви отримаєте візуальний розбір того, звідки походять байти. Зверніть увагу, що формат файлу залежить від інструменту створення: старіші версії на основі webpack генерують статистику webpack, тоді як новіші інструменти на основі esbuild створюють метадані esbuild, тому оберіть аналізатор, який розуміє формат вихідних даних вашого інструменту, та ознайомтесь з актуальною документацією Angular для вашої версії.

Типові причини повільної роботи додатку включають:

• одну бібліотеку стороннього виробника занадто великого розміру
• частини коду, які значно більші, ніж очікувалося
• однакові залежності, які пакуються більше одного разу
• кілька важких компонентів, які завантажуються під час початкового завантаження
• функції з опозданим завантаженням, які виявилися більшими, ніж планувалося

Жоден з цих елементів не є видимим лише з самого джерела. Порівняння статистики до та після оновлення залежностей — це простий спосіб виявити регресії.

Очистіть кеш збірки перед повторною установкою всього

CLI зберігає постійний дисковий кеш, щоб повторні збірки відбувалися швидше. Команда ng cache керує ним; ng cache info показує, де знаходиться кеш та чи він увімкнений:

ng cache

Коли збірки починають поводитися дивно, очищення цього кешу часто є рішенням проблеми:

ng cache clean

Старі записи кешу зазвичай з’являються після зміни залежностей, оновлення Angular або перемикання між гілками з різними версіями пакетів. Його очищення займає кілька секунд, тож спробуйте це зробити перед повільним способом — видаленням node_modules та повторною установкою.

Перевіряйте код локально та в CI

Якщо у вашому проекті налаштований інструмент перевірки коду, запустіть його за допомогою:

ng lint

У новіших версіях Angular за замовчуванням не входить інструмент лінтингу, тому команда ng lint працює лише після його додавання, зазвичай через інтеграцію Angular ESLint. Після налаштування він виявляє проблеми ще до того, як перевіряючий буде змушений:

• використовувати непотрібні змінні та імпорти
• стикатися з непослідовністю форматування
• знаходити можливі баги
• бачити небажані патерни
• стикатися з загальними проблемами якості коду

Виконання тієї самої команди в CI-пайплайні означає, що проблемний код позначається ще до того, як потрапить у основну гілку, і ніхто не повинен пам’ятати про його виконання.

Виконання тестів один раз у автоматизації

Локально тести зазвичай працюють у режимі спостереження та перезапускаються після кожної збереження:

ng test

У завданні CI немає сенсу використовувати процес, який чекає на зміни файлів. Вимкнення режиму спостереження змушує команду виконати набір тестів один раз та завершитися:

ng test --watch=false

Код вихіду відображає, чи пройшли тести, і саме цей показник використовується системою для позначення статусу завдання як «зелений» чи «червоний». Система, що перебуває у режимі спостереження, просто залишається у цьому стані до закінчення таймера. Локальна розробка та процеси інтеграційного тестування мають різні потреби, тож одна команда не повинна задовольняти обидві.

Вибрати окремий проект у багатопроєктному просторі роботи

Більші репозиторії Angular часто містять кілька додатків та бібліотек у одному просторі роботи. Більшість команд приймають назву проекту, тож ви можете скомпілювати лише один додаток:

ng build my-app

або протестувати лише один:

ng test my-app

У просторі роботи у стилі monorepo це стає звичайною практикою:

ng build admin
ng build customer
ng test shared-ui

Робота над спільною бібліотекою UI не повинна означати необхідність перекомпіляції кожного додатку; використання команд з обмеженим охопленням дозволяє зберігати короткі цикли зворотного зв’язку.

Викликати будь-який архітектурний об’єкт за допомогою ng run

За знайомими командами криється більш загальна команда, яку мало хто з розробників використовує безпосередньо:

ng run

Вона виконує вказану мету архітектора з конфігурації робочого простору, використовуючи формат project:target, з можливим додаванням назви конфігурації:

ng run my-app:build

Стандартні команди насправді є скороченнями для поширених мет. ng run стає корисним, коли робочий простір визначає власні мети, наприклад інструмент для генерації коду, розгортання прев’ю чи запуску спеціалізованих тестів. Уявіть собі це як „виконати саме цю мету цього проєкту“, без жодних додаткових припущень.

Відкрити документацію з терміналу

Коли вам потрібно швидко перевірити API, CLI може розпочати пошук за вас:

ng doc

Передайте ключове слово, і він знайде його у офіційній документації Angular:

ng doc signals

Зверніть увагу, що результати відкриваються у вашому браузері, а не виводяться у терміналі, тож це є швидким доступом до відповідної сторінки, а не офлайн-довідкою.

Нехай допомога замінить запам’ятовування

Мабуть, найкориснішою з усіх звичок є використання цієї команди:

ng help

Вона перелічує всі команди найвищого рівня. Щоб переглянути опції певної команди, додайте --help:

ng build --help

Те саме працює і з генераторами, навіть для окремої схеми:

ng generate service --help

Нікому не потрібно запам’ятовувати кожен флаг. Продуктивні розробники — це не ті, хто пам’ятає все; це ті, хто знає, де шукати, як тільки щось забуває.

Щоденний робочий процес, який це поєднує

Практична рутина може виглядати так: запустіть сервер розробки:

ng serve

Під час створення функціоналу генеруйте потрібне за допомогою відповідних флагів:

ng g c profile --skip-tests

Перед комітуванням перевірте код та запустіть тести один раз:

ng lint
ng test --watch=false

Для продакшн-білду використовуйте спеціально налаштовану конфігурацію для продакшну:

ng build --configuration production

Якщо є проблеми з розміром пакета, отримайте статистику:

ng build --stats-json

Якщо білд починає поводитися некоректно, спочатку очистіть кеш:

ng cache clean

А коли якась опція забувається, запитайте саму команду:

ng <command> --help

Підсумок

Angular CLI — це інструмент для підвищення продуктивності протягом усього циклу розробки, і найбільша користь досягається завдяки кільком опціям, які усувають повторну роботу:

• генерування коду за допомогою флагів замість ручного написання шаблонних кодів
• обмеження дії команд лише одному проекту у багатопроектних просторах роботи

Вимірюйте продуктивність пакетів за допомогою статистики замість припущень щодо їхньої роботи

Очистіть кеш перед повним перевстановленням

Виконуйте тести без режиму спостереження в CI та перевіряйте код після кожних змін

Покладайтеся на параметр --help, який завжди відповідає вашій встановленій версії

Наступного разу, коли ви відкриєте термінал у проекті Angular, пам’ятайте, що за ng криється набагато більше, ніж це:

ng serve