TheKoder dev diary #2

Konfiguracja webpack’a – podejście drugie! W dzisiejszym wpisie chciałbym podzielić się z Tobą jak wygląda proces budowania projektu.

Na początku chciałbym zaznaczyć, że w tym wpisie nie przedstawiam idei czym jest webpack ani kiedy go używać. W internecie jest masa artykułów które dobrze omawiają ten temat, jeżeli ktoś jest zainteresowany odsyłam tutaj i tutaj. Wpis nie jest też tutorialem gdzie omawiam jak dobrze skonfigurować to narzędzie i gdzie przedstawiam najlepsze praktyki jak z niego korzystać. Czym więc jest ten post? Napisałbym że wołaniem o pomoc, ale myślę, że aż tak źle nie jest 😉 Poniżej przedstawiam swoją podstawową konfigurację, być może komuś podsunie ona jakieś ciekawe rozwiązanie. Pisanie tego posta pomogło mi również poukładać w głowie najważniejsze koncepty webpacka, chociaż nie ukrywam że niektóre jego elementy są dla mnie dalej czarną magią.

Konfiguracja webpacka nigdy nie była moją mocną stroną, dlatego tym bardziej chciałem użyć go projekcie żeby mieć możliwość skonfigurowania go praktycznie od zera (w poprzednim wpisie wspominałem że korzystam ze startera). Jeżeli przypadkiem ten wpis czyta osoba bardziej doświadczona na tym polu jestem otwarty na sugestie dotyczące poprawek, które można wprowadzić do mojej konfiguracji.

Przechodząc do sedna – opis zacznę od najwyższego poziomu abstrakcji czyli skryptów, które pozwalają uruchomić webpacka w projekcie, przechodząc później do jego plików konfiguracyjnych. W pliku package.json znajdują się następujące linijki:

Właściwość scripts pozwala na zdefiniowanie własnych skryptów które następnie można uruchomić za pomocą npm’a np: npm run nazwa_skryptu
W tym przypadku mam zdefiniowane 3 skrypty:

  • dev – odpowiada za uruchomienie webpacka z domyślnym plikiem konfiguracyjnym przeznaczonym do prac developerskich oraz uruchomienie serwera lokalnego
  • test – uruchamia webpacka z konfiguracją dla testów jednostkowych, flaga -w zapewnia obserwowanie plików z testami i uruchamianie testów po każdej zmianie
  • deploy – uruchomienie webpacka z konfiguracją produkcyjną

Opiszę teraz co znajduję się w poszczególnych plikach konfiguracyjnych zaczynając od pliku domyślnego:

Właściwość entry jest punktem wejścia dla aplikacji. W moim przypadku jest ich właściwie dwa: app oraz vendor. app to właściwe pliki aplikacji które ulegają częstym zmianom i wymagają częstego budowania, vendor zaś to pliki bibliotek które praktycznie się nie zmieniają i nie wymagają każdorazowego budowania. CommonsChunkPlugin tworzy paczkę z takich bibliotek które po zbudowaniu lądują w folderze dist. W tym pliku warto jeszcze zwrócić uwagę na wykorzystanie expose-loadera. Został on tutaj użyty ponieważ biblioteki Phaser, Pixi i p2 korzystają z zależności w przestrzeni globalnej, a za udostępnienie ich odpowiada właśnie ten loader.
Konfigurację produkcyjną pozwolę sobie pominąć ponieważ różni się ona jedynie tym że dodatkowo minimalizuje pliki JavaScript i pozbywa się śmieci typu console.log(). Jeżeli ktoś chciałby rzucić okiem jak to wygląda to odsyłam do Githuba.

Ostatnią rzeczą którą chciałbym omówić to konfiguracja webpacka do testów jednostkowych. Poniżej znajdują snippety z dwóch plików które to umożliwiają:


Zadaniem skryptu z pliku get-tests.js jest dodanie wszystkich plików z końcówką *.test.js do kontekstu który później webpack wykorzysta jako punkt wejścia.
Głównym zadaniem tego pliku konfiguracyjnego jest stworzenie z plików zawierających testy jednego pliku i uruchomienie na nim frameworka mocha. Odbywa się to za pomocą pluginu WebpackShellPlugin który pozwala po zbudowaniu paczki na uruchomienie odpowiedniego skryptu.

Czas na podsumowanie! Wiem, że moja konfiguracja nie jest najlepsza ani najbardziej wydajna, ale na czas pierwszego sprintu wystarczy. Jak już wspominałem na początku, zapraszam do umieszczania swoich sugestii w komentarzu lub utworzenia pull request’a na Githubie. Konfiguracja webpacka dla kogoś kto ma o nim względne pojęcie i nie musiał tego wcześniej robić to droga przez mękę. No ale innego wyjścia nie ma – chcąc się tego nauczyć trzeba próbować 🙂 W tej konfiguracji nie udało mi się zaimplementować 2 rzeczy które zaplanowałem: live-reload przeglądarki oraz obserwowanie zmian w testach. Obecnie jeżeli jakiś test nie przejdzie, cały proces na którym działa mocha jest ubijany i trzeba startować go od nowa. Moim zdaniem webpack jednak nie sprawdza się najlepiej jako test runner, chciałem wszystko ograć za pomocą jednego narzędzia ale ostatecznie w drugim sprincie w tym celu zastąpie webpacka Gulpem.
To byłoby na tyle, a jakie jest Twoje zdanie na ten temat?

Leave a Comment

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *