Jak działa współczesny frontend, czyli Webpack cz. 1

Webpack, czyli prawdopodobnie najpopularniejszy bundler na rynku, służy do transpilacji kodu i plików źródłowych do postaci jednej, gotowej produkcyjnie paczki. We współczesnym frontendzie trudno by było tworzyć zaawansowane aplikacje webowe bez bundlerów. Omówmy zatem ich temat na przykładzie Webpacka.

Wprowadzenie

Temat ten dość długo odkładałem na blogu. Jest to o tyle ważny case, że w pracy frontendowca dziś raczej nie obejdzie się bez znajomości mechanizmów bundlowania. Nie mówię już tutaj o stricte Webpacku, bo na rynku istnieje masa różnych - lepszy lub gorszych - bundlerów, które możemy wykorzystać do budowy naszej aplikacji. Możesz więc zapytać, dlaczego Webpack? Przez co najmniej kilka powodów.

Po pierwsze, jest on wysoce konfigurowalny i możemy dostosować w nim masę rzeczy do własnych potrzeb. Jakbym miał porównać ten bundler do czegoś innego, to byłby to React w świecie frameworków: nic nas nie ogranicza i nic nie jest narzucone. Po drugie, jest to obecnie najpopularniejszy bundler na rynku, którego wykorzystuje masa trzecich bibliotek i modułów. Raczej nic nie wskazuje na to, żeby narzędzie to szybko umarło. I wreszcie po trzecie, można w nim zrobić dosłownie wszystko. Jeżeli wpadniemy na jakiś pomysł, który może usprawnić budowę lub pracę nad projektem, na 99.99% procent można to zrobić. Pomaga w tym oczywiście ogromne community wykorzystujące Webpacka.

Jeżeli interesują cię, jakie jeszcze są dostępne bundlery na rynku, to śpieszę z pomocą:

  • Parcel - bardzo szybki i mały bundler do JSa - minusem jest mała konfigurowalność narzędzia, raczej nie zalecam jego użycia do rozbudowanych aplikacji
  • Rollup - świetna alternatywa do Webpacka - nie ma tak ogromnej społeczności i nie ze wszystkim sobie radzi, ale nada się bardzo dobrze do np. bundlowania bibliotek npm
  • Gulp i Grunt - nie są to raczej bundlery, a raczej task runnery - rozwiązują natomiast podobne problemy, ale ich konfiguracja diametralnie się różni od Webpacka. Gulp to niegdyś ogromnie popularny task runner, którego tak naprawdę uśmiercił Webpack
  • Vite.js - dość nowy bundler, charakteryzujący się ogromną szybkością i dość niemałymi możliwościami konfiguracji - powiedziałbym, że jest to swego rodzaju środek pomiędzy Webpackiem a Parcelem
  • Typescript - będzie to może trochę nadużycie, ale TS jest swego rodzaju bundlerem, dzięki któremu w pewnych przypadkach możemy skonfigurować go do bundlowania plików, a tym samym zrezygnować z bundlera lub z części jego opcji

Są to tylko wybrane przykłady. Na rynku znajdziemy ich znacznie więcej, a jeżeli cię to interesuje, google it!

Jak działa Webpack w istocie?

Zacznijmy od niezbędnej teorii, która jest niesamowicie ważna w kontekście dalszego zrozumienia istoty narzędzi, jakim są bundlery. Zrobimy to oczywiście na przykładzie Webpacka. Po pierwsze i najważniejsze: Webpack działa i ma znaczenie tylko w kontekście budowania aplikacji / pisania kodu. Jest to typowy devDependency, którego na produkcji widzimy tylko wyniki działania w postaci wyrenderowanego kodu przez przeglądarkę. Webpack składa wszystkie pliki projektowe, które wskażemy w konfiguracji do jednej paczki, gotowej do uruchomienia na produkcji (lub nie - zależy od tego, jak go skonfigurowaliśmy 🙂 ). Taką manipulację plikami (strumień wejścia/wyjścia, edycja zawartości plików, czytanie ich itd.) umożliwia Node, przez co zyskał on ogromną popularność w świecie frontendu (a przecież w zamierzeniu powstał on jako język serwerowy). Jasne jest więc, że każdy bundler wymaga środowiska uruchomieniowego lokalnie. Najczęściej będzie to JavaScript na silniku V8, czyli właśnie Node, choć może być też Deno.

Przełomowym dla bundlerów momentem w historii frontendu była premiera ES6, który wprowadzał moduły w JavaScripcie (importy, exporty itd.). Wszystko byłoby w porządku, gdyby nie to, że trzeba było jakoś zapewnić wsparcie dla starszych wersji przeglądarek, które nowych mechanizmów i składni ES6 nie obsługiwały. Webpack umożliwia pisanie kodu JS w nowej składni, niekoniecznie dostępnej dla wszystkich, i bundlowanie (stąd nazewnictwo) jej do, przykładowo, jednego wielkiego pliku JS, z którymi starsze przeglądarki sobie spokojnie radzą. Wsteczna kompatybilność to jeden z aspektów, w którym Webpack nam pomaga. Ponadto, do Webpacka dostępna jest masa pluginów oraz loaderów, tworzonych przez społeczność.

Loadery

Webpack to nie tylko bundlowanie plików z kodem, ale i jego transpliacja / kompilacja. Pomagają w tym wszelakie loadery, które preprocesują kod i tworzą na jego podstawie gotowe do użycia pliki. Przykładowo, aby zapewnić wsteczną kompatybilność nowej składni JSa, użyjemy loaderów Babela. O Babelu pisałem więcej w tym wpisie. W skrócie, kompiluje on kod JS z nowych do starszych, wskazanych przez nas wersji. I tak, co nie działa w starszych wersjach przeglądarek, np. Promisy lub mapy, jest implementowane z wykorzystaniem starszych wersji ES, tym samym zapewniając działanie tych konstrukcji w jakichś starych wersjach IE.

zdjęcie tematyczne
Webpack automatyzuje wiele czynności

Oprócz tego istnieje masa innych loaderów, mające zastosowania w sytuacjach, takich jak: procesowanie kodu scss do zwyczajnego css, podmiana absolutnych ścieżek na relatywne, import różnych plików graficznych z wykorzystaniem łatwiejszych rozwiązań składniowych i wiele więcej. Dzięki loaderom Webpack zapewnia ogromny developer experience, gdzie normalnie - w przypadku kiedy takie rzeczy musimy robić ręcznie - on zapewnia nam z automatu.

Pluginy

Pluginy do Webpacka skupiają się na wszystkich tych rzeczach, które loadery nie mogą zrobić. Przykładowo, istnieje plugin minimize, służący do optymalizacji wynikowego kodu. Innym przykładem są różnego rodzaju pluginy do kompresji plików, jak pliki graficzne.

Podsumowanie

Webpack oraz wszelkie inne bundlery oraz task runnery to narzędzia zwiększające przede wszystkim produktywność programisty. Z ich pomocą możemy automatyzować czynności, które normalnie zajęłyby znacznie więcej czasu aniżeli jednorazowa konfiguracja tych narzędzi.

Nie poruszyłem dziś żadnych technicznych aspektów dot. Webpacka. Zajmiemy się tym w drugiej części z serii o tym narzędziu. W następnym wpisie skonfigurujemy projekt wykorzystujący Reacta à la Create React App, z tym wyjątkiem, że zrobimy to totalnie od podstaw. Nie pozostało mi więc już nic innego niż zaprosić cię do tej lektury. Do zobaczenia!

© Damian Kalka 2022
Wszelkie prawa zastrzeżone