Angular CLI poza ng serve: generatorzy, cele, cache oraz statystyki budowania

Większość programistów Angular szybko przyzwyczaja się do czterech poleceń: ng serve, ng build, ng generate i ng test, i nie szuka już niczego więcej. To wystarcza do małych aplikacji, ale w miarę rozwoju projektu czas poświęcony ręcznemu pisaniu szablonów, poszukiwaniu numerów wersji, ocenie rozmiaru plików i naprawianiu uszkodzonych buforów danych stopniowo rośnie. Interfejs wiersza poleceń oferuje już rozwiązania na większość tych zadań. Ten przewodnik omawia opcje, które warto wprowadzić jako standardową praktykę, wyjaśnia, w jakich sytuacjach każda z nich jest przydatna, i kończy się zwięzłym codziennym procesem pracy, który można przyjąć bez zmian.

Jeśli nadal jesteś na etapie tworzenia samego środowiska projektu, instrukcje dotyczące tworzenia nowoczesnego projektu Angular obejmują ten etap; wszystko poniżej zakłada, że projekt już istnieje.

Wykorzystaj ng generate w pełni

Generator to komenda, którą wszyscy znają w swojej pełnej formie:

ng generate component user-profile

Każdy generator ma krótki alias, więc generate staje się g, a component – c:

ng g c user-profile

Prawdziwa oszczędność pochodzi od flag. Gdy mała komponenta prezentacyjna nie wymaga pliku specyfikacji, --skip-tests zapobiega jego tworzeniu przez interfejs wiersza poleceń:

ng g c user-profile --skip-tests

Domyślnie każda komponenta trafia do osobnej folderu. --flat zamiast tego zapisuje pliki bezpośrednio w aktualnej katalogu, co nadaje się do małych komponentów znajdujących się obok swojego rodzica:

ng g c user-profile --flat

Flagi mogą być łączone, więc można je używać jednocześnie:

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

Treść ta dotyczy również usług, dyrektyw, rurek przepływu danych, mechanizmów ochronnych oraz innych schematów. Pozwolenie generatorowi na tworzenie plików zapewnia spójność nazewnictwa i układu w całym zespole. Dodaj --dry-run, aby zobaczyć, co stworzyłby dany schemat, bez konieczności pisania żadnych treści.

Zadaj pytanie interfejsowi CLI zamiast szukać w internecie

Najszybszym sposobem na dowiedzenie się, co potrafi generator, jest zadanie mu pytania. Dzięki temu otrzymasz listę wszystkich dostępnych schematów:

ng generate --help

Alias działa w ten sam sposób:

ng g --help

Dodanie --help po określonym schemacie wyświetla wszystkie jego opcje wraz z krótkimi opisami:

ng g component --help

Opcje zmieniają się pomiędzy różnymi wersjami, a odpowiedzi na forach często dotyczą starszych flag; wyjście z funkcji pomocy zawsze odpowiada interfejsowi CLI zainstalowanemu w twoim projekcie.

Czytaj i zmieniaj ustawienia za pomocą ng config

Konfiguracja przestrzeni roboczej znajduje się w pliku angular.json, i jest kuszące, by edytować ten plik bezpośrednio. CLI oferuje polecenie do czytania i zapisywania tych wartości:

ng config

Gdy zostanie wywołane samodzielnie, wyświetla konfigurację, dzięki czemu można zobaczyć, co zostało ustawione:

ng config

Można również przekazać ścieżkę JSON, aby odczytać jedną wartość, lub ścieżkę połączoną z wartością, aby ją ustawić – na przykład w celu zmiany opcji CLI dla całej przestrzeni roboczej. W skryptach powtarzalne wywołanie ng config jest lepsze od nietrwałych ręcznych edycji pliku JSON: jeśli plik jest zarządzany przez CLI, użyj CLI do jego zmiany.

Zgłoś swoje środowisko za pomocą wersji ng

Gdy coś się zepsuje, istotne są dokładne wersje. Zamiast otwierać plik package.json i próbować wszystko skombinować, uruchom:

ng version

lub jego skróconą formę:

ng v

Wynik przedstawia w jednym bloku wersję Angular CLI, zainstalowane pakiety Angular, Node.js, menedżera pakietów oraz system operacyjny. To dokładnie to, czego potrzebuje kolega z zespołu lub administrator, gdy prosimy o pomoc. Raport zawierający jedynie informację o przerwaniu działania projektu nie daje im żadnych wskazówek, natomiast skopiowanie wyniku poniższego polecenia odpowiada już na pierwsze pięć pytań:

ng version

Mierz rozmiar pliku produkcyjnego zamiast zgadywać

To flaga kompilacji zasługuje na znacznie częstszego używania, niż to się dzieje:

ng build --stats-json

Zapisuje plik statystyk opisujący zawartość każdego fragmentu wyjściowego. Podaj ten plik do analizatora pakietów, a otrzymasz wizualny podział pokazujący, skąd pochodzą bajty. Należy pamiętać, że format pliku zależy od narzędzia budowania: starsze wersje oparte na webpack generują statystyki webpack, natomiast nowsze narzędzia oparte na esbuild wytwarzają metadane esbuild, więc wybierz analizator, który rozumie wyniki Twojego narzędzia, i sprawdź aktualne dokumentacje Angular dla swojej wersji.

Typowe problemy, gdy aplikacja wydaje się wolna, to:

• jedna zbyt duża biblioteka od third party
• fragmenty znacznie większe niż oczekiwano
• ta sama zależność zapakowana więcej niż raz
• kilka ciężkich komponentów ładowanych przy pierwszym uruchomieniu
• funkcje ładowane w tle, które okazały się większe niż planowano

Żadna z tych rzeczy nie jest widoczna samodzielnie na podstawie źródła. Porównywanie statystyk przed i po aktualizacji zależności to tani sposób na wykrycie regresji.

Wyczyść cache budowania przed ponowną instalacją wszystkiego

CLI przechowuje trwały cache na dysku, dzięki czemu powtarzane budowania są szybsze. Komenda ng cache nim zarządza; ng cache info pokazuje, gdzie znajduje się cache oraz czy jest włączony:

ng cache

Gdy budowanie zaczyna zachowywać się dziwnie, często rozwiązaniem jest wyczyśczenie tego cache’u:

ng cache clean

Przestarzałe wpisy cache’u pojawiają się zwykle po zmianie zależności, aktualizacji Angulara lub przejściu między gałęziami z różnymi wersjami pakietów. Wyczyśczenie zajmuje kilka sekund, więc spróbuj tego zanim przejdziesz do wolniejszej metody usuwania folderu node_modules i ponownej instalacji.

Lintowanie lokalnie i w CI

Jeśli w twoim projekcie jest skonfigurowany linter, uruchom go za pomocą:

ng lint

W najnowszych wersjach Angulara domyślnie nie jest dostępny linter, więc ng lint działa tylko po dodaniu takiego narzędzia, zwykle poprzez integrację Angular ESLint. Po konfiguracji wykrywa on problemy, zanim recenzent będzie musiał:

• obsługiwać nieużywane zmienne i importy
• naprawiać niespójności w formacie kodu
• wykrywać potencjalne błędy
• unikać niezalecanych wzorców
• rozwiązywać ogólne problemy z jakością kodu

Wykonanie tego samego polecenia w pipeline CI oznacza, że problematyczny kod jest zaznaczany przed dotarciem do głównej gałęzi, a nikt nie musi pamiętać o jego uruchomieniu.

Rozegranie testów raz w procesie automatycznym

Lokalnie testy zazwyczaj pozostają w trybie obserwacji i są ponownie uruchamiane przy każdej zapisaniu pliku:

ng test

Zadanie w CI nie ma zastosowania dla procesu, który czeka na zmiany plików. Wyłączenie trybu obserwacji sprawia, że polecenie uruchamia zestaw testów raz i zakończa pracę:

ng test --watch=false

Kod wyjścia odzwierciedla wtedy, czy testy przeszły, a to właśnie służy pipeline’owi do oznaczenia zadania jako zielonego lub czerwonego. Pipeline pozostawiony w trybie obserwacji po prostu czeka, aż upłynie czas timeoutu. Rozwój lokalny i CI mają różne potrzeby, więc jedna linia poleceń nie musi służyć obu.

Celuj w pojedynczy projekt w środowisku wieloprojektowym

Bardziej rozbudowane repozytoria Angulara często zawierają kilka aplikacji i bibliotek w jednym środowisku. Większość poleceń przyjmuje nazwę projektu, więc można zbudować tylko jedną aplikację:

ng build my-app

lub przetestować tylko jedną:

ng test my-app

W środowisku w stylu monorepo to staje się rutyną:

ng build admin
ng build customer
ng test shared-ui

Praca nad wspólną biblioteką interfejsu nie powinna oznaczać ponownego budowania każdej aplikacji; precyzyjne określanie zakresu poleceń skraca pętle zwrotne.

Wezwij dowolny cel architektoniczny za pomocą ng run

Za tymi znajomymi poleceniami kryje się jedno bardziej ogólne, którego niewielu programistów używa bezpośrednio:

ng run

Wykonuje ono określony cel architektoniczny z konfiguracji przestrzeni roboczej, korzystając z formy project:target, opcjonalnie z dodanym nazwą konfiguracji:

ng run my-app:build

Standardowe polecenia to w rzeczywistości skróty do często używanych celów. ng run staje się przydatne, gdy przestrzeń robocza definiuje własne cele, na przykład narzędzie do generowania kodu, wdrażania wersji próbnej lub uruchamiania specjalistycznych testów. Można to postrzegać jako „wykonaj dokładnie ten cel tego projektu”, bez żadnych domysłów.

Otwórz dokumentację z terminala

Gdy potrzebujesz szybko sprawdzić API, interfejs wiersza poleceń może rozpocząć dla ciebie wyszukiwanie:

ng doc

Podaj słowo kluczowe, a narzędzie poszuka go w oficjalnej dokumentacji Angulara:

ng doc signals

Proszę pamiętać, że wyniki otwierają się w przeglądarce, a nie są wyświetlane w terminalu, więc jest to skrót do odpowiedniej strony, a nie materiał referencyjny do pracy offline.

Pozwól pomocnikowi zastąpić zapamiętywanie

Pośrednio najprzydatniejszym nawykiem jest użycie tego polecenia:

ng help

Wyświetla ono wszystkie polecenia najwyższego poziomu. Aby zobaczyć opcje konkretnego polecenia, dodaj --help:

ng build --help

To samo dotyczy generatorów, nawet w przypadku pojedynczego schematu:

ng generate service --help

Nikt nie musi zapamiętywać wszystkich flag. Produktywni programiści to rzadko ci, którzy pamiętają wszystko; to ci, którzy wiedzą, gdzie szukać, gdy o coś zapomną.

Dzienny proces pracy, który to łączy

Prawdopodobna praktyczna rutyna wyglądałaby w następujący sposób. Uruchom serwer rozwojowy:

ng serve

Podczas tworzenia funkcjonalności generuj to, czego potrzebujesz, używając odpowiednich flag:

ng g c profile --skip-tests

Przed zapisaniem zmian sprawdź kod i uruchom testy raz:

ng lint
ng test --watch=false

Dla budowy produkcyjnej wyraźnie użyj konfiguracji produkcyjnej:

ng build --configuration production

Gdy chodzi o rozmiar pliku, wygeneruj statystyki:

ng build --stats-json

Gdy budowa zaczyna zachowywać się niewłaściwie, najpierw wyczyść cache:

ng cache clean

A zawsze, gdy zapomnisz o jakiejś opcji, zapytaj sam komendę:

ng <command> --help

Podsumowanie

Angular CLI to warstwa zwiększająca produktywność w całym cyklu rozwoju, a największe korzyści wynikają z kilku opcji eliminujących pracę powtarzalną:

• generowanie kodu za pomocą flag zamiast ręcznego pisania szablonów
• skupianie komend na jednym projekcie w przestrzeniach roboczych wieloprojektowych

pomiar pakietów za pomocą statystyk zamiast domyślania się wydajności

usuwanie pamięci cache przed pełną reinstalacją

wykonywanie testów bez trybu obserwacji w CI oraz sprawdzanie kodu po każdej zmianie

korzystanie z opcji --help, która zawsze odpowiada zainstalowanej wersji

Następnym razem, gdy otworzysz terminal w projekcie Angular, pamiętaj, że za ng kryje się o wiele więcej niż to:

ng serve

Literatura pokrewna

• Szybszy Angular robiąc mniej: Dziesięć technik poza OnPush i trackBy — Redukcja marnotrawstwa zasobów sieciowych, reaktywnych, DOM i CPU w nowoczesnym Angular dzięki @defer, stopniowej hydratacji, resource(), sygnałom obliczonym, fazom renderowania i Web Workers.
• Migracja aplikacji Angular z Webpack Builder do @angular/build — Przewodnik krok po kroku dotyczący zastąpienia narzędzia Webpack używanego przez Angular narzędziem opartym na esbuild, poprawy ścieżek wyjściowych plików, obsługi SSR, loaderów oraz typów w tsconfig.
• Generatorzy stron statycznych od zera: słownictwo, historia i pierwsza kompilacja — Poznaj terminy, których przyjęto, że znasz w dokumentacji dotyczącej generatorów stron statycznych, zobacz, jak ze sobą łączą się layouty, części wspólne i front matter, dowiedz się, skąd pochodzą te narzędzia, oraz jak wybrać odpowiedni bez trudności.