Pierwsze kroki z pakietem internetowym
Opublikowany: 2022-03-10We wczesnych dniach, kiedy modułowość została wprowadzona w JavaScript, nie było natywnego wsparcia dla uruchamiania modułów w przeglądarce. Wsparcie dla programowania modułowego zostało zaimplementowane w Node.js przy użyciu planu CommonJS i zostało zaadoptowane przez tych, którzy używają JavaScript do budowania aplikacji po stronie serwera.
Miał również perspektywy dla dużych aplikacji internetowych, ponieważ programiści mogli uniknąć kolizji przestrzeni nazw i zbudować bardziej łatwe w utrzymaniu bazy kodu, pisząc kod w bardziej modułowym wzorcu. Ale wciąż było wyzwanie: moduły nie mogły być używane w przeglądarkach internetowych, gdzie zwykle wykonywany był JavaScript.
Aby rozwiązać ten problem, napisano pakiety modułów, takie jak webpack, Parcel, Rollup, a także Google Closure Compiler, aby utworzyć zoptymalizowane pakiety kodu dla przeglądarki użytkownika końcowego do pobrania i wykonania.
Co to znaczy „pakować” swój kod?
Kod pakietowy odnosi się do łączenia i optymalizacji wielu modułów w jeden lub więcej pakietów gotowych do produkcji . Wspomnianą tu wiązkę można lepiej zrozumieć jako produkt końcowy całego procesu wiązania.
W tym artykule skupimy się na webpacku, narzędziu napisanym przez Tobiasa Koppersa, które z biegiem czasu stało się głównym narzędziem w łańcuchu narzędzi JavaScript, często używanym w dużych i małych projektach.
Uwaga: aby skorzystać z tego artykułu, warto zapoznać się z modułami JavaScript. Będziesz także potrzebować Node zainstalowanego na twoim lokalnym komputerze, dzięki czemu będziesz mógł zainstalować i używać webpack lokalnie.
Co to jest pakiet internetowy?
webpack to wysoce rozszerzalny i konfigurowalny pakiet modułów statycznych dla aplikacji JavaScript. Dzięki swojej rozszerzalności możesz podłączyć zewnętrzne programy ładujące i wtyczki, aby osiągnąć swój cel końcowy.
Jak pokazano na poniższej ilustracji, pakiet webpack przechodzi przez aplikację z głównego punktu wejścia , tworzy wykres zależności składający się z zależności, które działają bezpośrednio lub pośrednio na plik główny i tworzy zoptymalizowane pakiety połączonych modułów.
Aby zrozumieć, jak działa webpack, musimy zrozumieć pewną używaną przez niego terminologię (sprawdź słownik webpack. Terminologia ta jest często używana w tym artykule, a także jest często przywoływana w dokumentacji webpacka.
- Kawałek
Fragment odnosi się do kodu wyodrębnionego z modułów. Ten kod będzie przechowywany w pliku porcji . Kawałki są powszechnie używane podczas dzielenia kodu za pomocą pakietu webpack. - Moduły
Moduły to podzielone części aplikacji, które importujesz w celu wykonania określonego zadania lub funkcji. Webpack obsługuje moduły utworzone przy użyciu składni ES6, CommonJS i AMD. - Aktywa
Termin „ zasoby ” jest często używany w pakietach internetowych i ogólnie w innych pakietach. Odnosi się do plików statycznych dołączonych podczas procesu budowania. Pliki te mogą obejmować wszystko, od obrazów po czcionki, a nawet pliki wideo. Czytając dalej artykuł, zobaczysz, jak używamy programów ładujących do pracy z różnymi typami zasobów.
Zalecana literatura : Pakiet internetowy - szczegółowe wprowadzenie
Kiedy już zrozumiemy, czym jest webpack i jakiej terminologii używa, zobaczmy, jak mają one zastosowanie w tworzeniu pliku konfiguracyjnego dla projektu demonstracyjnego.
Uwaga : Będziesz także potrzebował zainstalowanego webpack-cli
, aby używać pakietu webpack na swoim komputerze. Jeśli nie jest zainstalowany, zostaniesz poproszony z terminala o jego zainstalowanie.
Pliki konfiguracyjne pakietu webpack
Oprócz używania webpack-cli z terminala, możesz również użyć webpacka w swoim projekcie za pomocą pliku konfiguracyjnego. Ale dzięki najnowszym wersjom webpacka możemy go używać w naszym projekcie bez pliku konfiguracyjnego. Możemy użyć webpack
jako wartości jednego z poleceń w naszym pliku package.json
— bez żadnej flagi. W ten sposób webpack przyjmie, że plik punktu wejścia twojego projektu znajduje się w katalogu src
. Spakuje plik wejściowy i wyśle go do katalogu dist
.
Przykładem jest poniższy przykładowy plik package.json
. Tutaj używamy webpacka do spakowania aplikacji bez pliku konfiguracyjnego:
{ "name" : "Smashing Magazine", "main": "index.js", "scripts": { "build" : "webpack" }, "dependencies" : { "webpack": "^5.24.1" } }
Po uruchomieniu polecenia budowania w powyższym pliku, webpack spakuje plik w katalogu src/index.js
i wyśle go do pliku main.js
w katalogu dist
. webpack jest jednak znacznie bardziej elastyczny. Możemy zmienić punkt wejścia , dostosować punkt wyjścia i udoskonalić wiele innych domyślnych zachowań, edytując plik konfiguracyjny z flagą -- config
.
Przykładem jest zmodyfikowane polecenie build z powyższego pliku package.json
:
"build" : "webpack --config webpack.config.js"
Powyżej dodaliśmy flagę --config
i webpack.config.js
jako plik z nową konfiguracją webpacka.
Plik webpack.config.js
jednak jeszcze nie istnieje. Musimy więc utworzyć go w naszym katalogu aplikacji i wkleić poniższy kod do pliku.
# webpack.config.js const path = require("path") module.exports = { entry : "./src/entry", output : { path: path.resolve(__dirname, "dist"), filename: "output.js" } }
Powyższy plik nadal konfiguruje webpack tak, aby zawierał twój plik JavaScript, ale teraz możemy zdefiniować niestandardowe ścieżki wejścia i pliku wyjściowego zamiast domyślnej ścieżki używanej przez webpack.
Kilka rzeczy do zapamiętania na temat pliku konfiguracyjnego webpacka:
- Plik konfiguracyjny pakietu webpack to plik JavaScript, napisany jako moduł JavaScript CommonJS.
- Plik konfiguracyjny pakietu webpack eksportuje obiekt z kilkoma właściwościami. Każda z tych właściwości jest używana jako opcja do konfigurowania pakietu internetowego podczas dołączania kodu. Przykładem jest opcja
mode
:-
mode
W konfiguracji ta opcja służy do ustawiania wartościNODE_ENV
podczas łączenia. Może mieć wartośćproduction
lubdevelopment
. Jeśli nie zostanie określony, domyślnie zostanie ustawionynone
. Ważne jest również, aby pamiętać, że pakiet internetowy różni się pakietami zasobów w zależności od wartościmode
. Na przykład pakiet webpack automatycznie buforuje pakiety w trybie programistycznym, aby zoptymalizować i skrócić czas pakietu. Zapoznaj się z sekcją trybów w dokumentacji pakietu webpack, aby zobaczyć dziennik zmian opcji automatycznie zastosowanych w każdym trybie.
-
Koncepcje webpack
Podczas konfigurowania pakietu internetowego za pomocą interfejsu wiersza polecenia lub pliku konfiguracyjnego istnieją cztery główne koncepcje , które są stosowane jako opcje . W następnej sekcji tego artykułu skupiono się na tych pojęciach i zastosowano je podczas tworzenia konfiguracji demonstracyjnej aplikacji internetowej.
Należy pamiętać, że koncepcje wyjaśnione poniżej mają pewne podobieństwa z innymi pakietami modułów. Na przykład podczas korzystania z pakietu zbiorczego z plikiem konfiguracyjnym można zdefiniować pole wejściowe, aby określić punkt wejścia wykresu zależności, obiekt wyjściowy konfigurujący sposób i miejsce umieszczania utworzonych fragmentów, a także obiekt wtyczek do dodawania zewnętrznych wtyczek.
Wejście
Pole wejściowe w pliku konfiguracyjnym zawiera ścieżkę do pliku, z którego pakiet webpack rozpoczyna tworzenie grafu zależności . Z tego pliku wejściowego webpack przejdzie do innych modułów, które zależą bezpośrednio lub pośrednio od punktu wejścia.
Punktem wejścia konfiguracji może być wpis typu Single Entry z pojedynczą wartością pliku, podobnie jak w poniższym przykładzie:
# webpack.configuration.js module.exports = { mode: "development", entry : "./src/entry" }
Punkt wejścia może być również typem wpisu z wieloma głównymi danymi, posiadającym tablicę zawierającą ścieżkę do kilku plików wpisów, podobnie jak w poniższym przykładzie:
# webpack.configuration.js const webpack = require("webpack") module.exports = { mode: "development", entry: [ './src/entry', './src/entry2' ], }
Wyjście
Jak sama nazwa wskazuje, pole wyjściowe konfiguracji to miejsce, w którym będzie znajdować się utworzony pakiet. To pole przydaje się, gdy masz kilka modułów. Zamiast używać nazwy generowanej przez pakiet webpack, możesz określić własną nazwę pliku .
# webpack.configuration.js const webpack = require("webpack"); const path = require("path"); module.exports = { mode: "development", entry: './src/entry', output: { filename: "webpack-output.js", path: path.resolve(__dirname, "dist"), } }
Ładowarki
Domyślnie webpack rozpoznaje tylko pliki JavaScript w Twojej aplikacji. Jednak pakiet webpack traktuje każdy plik importowany jako moduł jako zależność i dodaje go do wykresu zależności. Aby przetworzyć zasoby statyczne, takie jak obrazy, pliki CSS, pliki JSON, a nawet dane przechowywane w CSV, webpack używa programów ładujących, aby „załadować” te pliki do pakietu.
Programy ładujące są wystarczająco elastyczne, aby można je było wykorzystać do wielu rzeczy, od transpilacji kodu ES, po obsługę stylów aplikacji, a nawet linting kodu za pomocą ESLint.
Istnieją trzy sposoby wykorzystania programów ładujących w Twojej aplikacji. Jednym z nich jest metoda inline poprzez bezpośrednie importowanie go do pliku. Na przykład, aby zminimalizować rozmiar obrazu, możemy użyć programu image-loader
bezpośrednio w pliku, jak pokazano poniżej:
// main.js import ImageLoader from 'image-loader'
Inną preferowaną opcją korzystania z programów ładujących jest użycie pliku konfiguracyjnego pakietu webpack. W ten sposób możesz zrobić więcej z programami ładującymi, na przykład określić typy plików , do których chcesz zastosować moduły ładujące. Aby to zrobić, tworzymy tablicę rules
i określamy moduły ładujące w obiekcie, z których każdy ma pole testowe z wyrażeniem regularnym pasującym do zasobów, do których chcemy zastosować moduły ładujące.
Na przykład z image-loader
zaimportowanym bezpośrednio w poprzednim przykładzie, możemy go użyć w pliku konfiguracyjnym webpacka z najbardziej podstawowymi opcjami z dokumentacji. Będzie to wyglądać tak:
# webpack.config.js const webpack = require("webpack") const path = require("path") const merge = require("webpack-merge") module.exports = { mode: "development", entry: './src/entry', output: { filename: "webpack-output.js", path: path.resolve(__dirname, "dist"), }, module: { rules: [ { test: /\.(jpe?g|png|gif|svg)$/i, use: [ 'img-loader' ] } ] } }
Przyjrzyj się bliżej polu test
w obiekcie, który zawiera powyższy image-loader
. Możemy zauważyć wyrażenie regularne pasujące do wszystkich plików graficznych: w formacie jp(e)g
, png
, gif
i svg
.
Ostatnią metodą użycia Loaderów jest użycie CLI z --module-bind
.
Readme awesome-webpack zawiera wyczerpującą listę programów ładujących , których można używać z webpackiem, każdy pogrupowany w kategorie operacji, które wykonują. Poniżej znajduje się tylko kilka ładowarek, które mogą się przydać w Twojej aplikacji:
- Responsive-loader Ten moduł ładujący będzie bardzo pomocny podczas dodawania obrazów, które pasują do responsywnej witryny lub aplikacji. Tworzy wiele obrazów o różnych rozmiarach z jednego obrazu i zwraca zestaw
srcset
pasujący do obrazów do użycia w odpowiednich rozmiarach ekranu. - Ładowarka Babel
Służy do transpilacji kodu JavaScript z nowoczesnej składni ECMA do ES5. - Program ładujący GraphQL
Jeśli jesteś entuzjastą GraphQL, ten moduł ładujący okaże się bardzo pomocny, ponieważ ładuje pliki.graphql
zawierające Twój schemat GraphQL, zapytania i mutacje — wraz z opcją włączenia walidacji.
Wtyczki
Użycie wtyczek pozwala kompilatorowi webpack na wykonywanie zadań na porcjach wyprodukowanych z dołączonych modułów. Chociaż webpack nie jest uruchamiaczem zadań, dzięki wtyczkom możemy wykonać pewne niestandardowe akcje, których loadery nie mogły wykonać, gdy kod był pakowany.
Przykładem wtyczki webpack jest ProgressPlugin wbudowana w webpack. Umożliwia dostosowanie postępu, który jest wypisywany w konsoli podczas kompilacji.
# webpack.config.js const webpack = require("webpack") const path = require("path") const merge = require("webpack-merge") const config = { mode: "development", entry: './src/entry', output: { filename: "webpack-output.js", path: path.resolve(__dirname, "dist"), }, module: { rules: [ { test: /\.(jpe?g|png|gif|svg)$/i, use: [ 'img-loader' ] } ] }, plugins: [ new webpack.ProgressPlugin({ handler: (percentage, message ) => { console.info(percentage, message); }, }) ] } module.exports = config
Wraz z wtyczką Progress w powyższej konfiguracji udostępniliśmy funkcję obsługi , która wypisuje procent kompilacji i komunikat do konsoli podczas procesu kompilacji.
Poniżej znajduje się kilka wtyczek z readme awesome-webpack, które przydadzą się w Twojej aplikacji webpack.
- Wtyczka offline
Ta wtyczka najpierw wykorzystuje Service Workery lub AppCache, jeśli jest dostępna, aby zapewnić środowisko offline dla projektów zarządzanych przez pakiety Webpack. - Wtyczka-purgecss-webpack
Ta wtyczka przydaje się, gdy próbujesz zoptymalizować projekt webpacka, ponieważ usuwa nieużywane CSS z Twojej aplikacji podczas kompilacji.
W tym momencie mamy naszą pierwszą konfigurację webpacka dla stosunkowo małej aplikacji w pełni skonfigurowanej. Zastanówmy się dalej, jak możemy zrobić pewne rzeczy z webpackiem w naszej aplikacji.
Obsługa wielu środowisk
W Twojej aplikacji może być konieczne inne skonfigurowanie pakietu webpack dla środowiska programistycznego lub produkcyjnego . Na przykład możesz nie chcieć, aby pakiet sieci Web wyprowadzał drobne dzienniki ostrzeżeń za każdym razem, gdy w potoku ciągłej integracji w środowisku produkcyjnym zostanie wykonane nowe wdrożenie.
Jest kilka sposobów na osiągnięcie tego, zgodnie z zaleceniami webpacka i społeczności. Jednym ze sposobów jest przekonwertowanie pliku konfiguracyjnego w celu wyeksportowania funkcji zwracającej obiekt. W ten sposób bieżące środowisko zostanie przekazane do funkcji przez kompilator webpack jako pierwszy parametr, a druga opcja jako drugi parametr.
Ta metoda obsługi środowiska webpack przyda się, jeśli istnieje kilka operacji, które chciałbyś wykonać inaczej w zależności od bieżącego środowiska. Jednak w przypadku większych aplikacji z bardziej złożonymi konfiguracjami możesz otrzymać konfigurację zawierającą wiele instrukcji warunkowych.
Poniższy fragment kodu przedstawia przykład obsługi środowiska production
i development
w tym samym pliku przy użyciu metody functions
.
// webpack.config.js module.exports = function (env, args) { return { mode : env.production ? 'production' : 'development', entry: './src/entry', output: { filename: "webpack-output.js", path: path.resolve(__dirname, "dist"), }, plugins: [ env.development && ( new webpack.ProgressPlugin({ handler: (percentage, message ) => { console.info(percentage, message); }, }) ) ] } }
Przeglądając wyeksportowaną funkcję w powyższym fragmencie kodu, zobaczysz, jak parametr env
przekazany do funkcji jest używany z operatorem trójargumentowym do przełączania wartości. Najpierw jest używany do ustawienia trybu webpack, a następnie jest używany do włączania ProgressPlugin tylko w trybie programistycznym.
Innym bardziej eleganckim sposobem obsługi środowiska produkcyjnego i programistycznego jest utworzenie różnych plików konfiguracyjnych dla dwóch środowisk. Kiedy już to zrobimy, możemy ich używać z różnymi poleceniami w skryptach package.json
podczas łączenia aplikacji. Spójrz na poniższy fragment:
{ "name" : "smashing-magazine", "main" : "index.js" "scripts" : { "bundle:dev" : "webpack --config webpack.dev.config.js", "bundle:prod" : "webpack --config webpack.prod.config.js" }, "dependencies" : { "webpack": "^5.24.1" } }
W powyższym package.json
mamy dwa polecenia skryptowe , z których każde używa innego pliku konfiguracyjnego napisanego w celu obsługi określonego środowiska podczas łączenia zasobów aplikacji. Teraz możesz powiązać aplikację przy użyciu npm run bundle:dev
w trybie programistycznym lub npm run bundle:prod
podczas tworzenia pakietu gotowego do produkcji.
Korzystając z drugiego podejścia, unikasz instrukcji warunkowych wprowadzanych podczas zwracania obiektu konfiguracyjnego z funkcji. Jednak teraz musisz również utrzymywać wiele plików konfiguracyjnych.
Dzielenie pliku konfiguracyjnego
W tym momencie nasz plik konfiguracyjny webpacka ma 38 wierszy kodu (LOC). Jest to całkiem dobre dla aplikacji demonstracyjnej z jednym programem ładującym i jedną wtyczką.
Jednak w przypadku większych aplikacji nasz plik konfiguracyjny webpacka z pewnością będzie znacznie dłuższy i będzie zawierał kilka programów ładujących i wtyczek z ich niestandardowymi opcjami. Aby plik konfiguracyjny był czysty i czytelny, możemy podzielić konfigurację na mniejsze obiekty w wielu plikach, a następnie użyć pakietu webpack-merge, aby scalić obiekty konfiguracyjne w jeden plik podstawowy.
Aby zastosować go do naszego projektu webpack, możemy podzielić pojedynczy plik konfiguracyjny na trzy mniejsze pliki: jeden dla programów ładujących, jeden dla wtyczek i ostatni plik jako podstawowy plik konfiguracyjny, w którym umieściliśmy dwa inne pliki razem.
Utwórz plik webpack.plugin.config.js
i wklej do niego poniższy kod, aby korzystać z wtyczek z dodatkowymi opcjami.
// webpack.plugin.config.js const webpack = require('webpack') const plugin = [ new webpack.ProgressPlugin({ handler: (percentage, message ) => { console.info(percentage, message); }, }) ] module.exports = plugin
Powyżej mamy jedną wtyczkę, którą wyodrębniliśmy z pliku webpack.configuration.js
.
Następnie utwórz plik webpack.loader.config.js
z poniższym kodem dla programów ładujących pakiety webpack.
// webpack.loader.config.js const loader = { module: { rules: [ { test: /\.(jpe?g|png|gif|svg)$/i, use: [ 'img-loader' ] } ] } }
W powyższym bloku kodu przenieśliśmy webpack img-loader
do osobnego pliku.
Na koniec utwórz plik webpack.base.config.js
, w którym podstawowa konfiguracja wejściowa i wyjściowa dla aplikacji webpack będzie przechowywana wraz z dwoma utworzonymi powyżej plikami.
// webpack.base.config.js const path = require("path") const merge = require("webpack-merge") const plugins = require('./webpack.plugin.config') const loaders = require('./webpack.loader.config') const config = merge(loaders, plugins, { mode: "development", entry: './src/entry', output: { filename: "webpack-output.js", path: path.resolve(__dirname, "dist"), } }); module.exports = config
Rzut oka na powyższy plik webpack można zaobserwować, jak kompaktowy jest w porównaniu z oryginalnym plikiem webpack.config.js
. Teraz trzy główne części konfiguracji zostały podzielone na mniejsze pliki i mogą być używane indywidualnie.
Optymalizacja dużych konstrukcji
W miarę jak będziesz pracować nad swoją aplikacją przez pewien czas, Twoja aplikacja z pewnością powiększy się pod względem funkcji i rozmiaru. Gdy tak się stanie, nowe pliki zostaną utworzone, stare pliki zostaną zmodyfikowane lub zrefaktoryzowane, a nowe pakiety zewnętrzne zostaną zainstalowane — wszystko to prowadzi do zwiększenia rozmiaru pakietu emitowanego przez webpack.
Domyślnie webpack automatycznie próbuje zoptymalizować pakiety w Twoim imieniu, jeśli tryb konfiguracji jest ustawiony na production
. Na przykład jedną z technik, które webpack stosuje domyślnie (zaczynając od webpacka 4+), aby zoptymalizować i zmniejszyć rozmiar pakietu, jest Tree-Shaking. Zasadniczo jest to technika optymalizacji służąca do usuwania nieużywanego kodu. Na prostym poziomie podczas pakowania, instrukcje importu i eksportu służą do wykrywania nieużywanych modułów przed usunięciem ich z emitowanych pakietów.
Pakiet aplikacji można również zoptymalizować ręcznie , dodając do pliku konfiguracyjnego obiekt optimization
z określonymi polami. Sekcja dotycząca optymalizacji dokumentacji pakietu webpack zawiera pełną listę pól, których można użyć w obiekcie optimization
, aby, no cóż, zoptymalizować swoją aplikację. Rozważmy jedno z 20 udokumentowanych pól.
-
minimize
To pole logiczne służy do instruowania pakietu webpack, aby zminimalizował rozmiar pakietu. Domyślnie webpack będzie próbował to osiągnąć za pomocą TerserPlugin, pakietu minimalizacji kodu dostarczanego z webpackiem.
Minifikacja dotyczy minimalizacji kodu poprzez usunięcie niepotrzebnych danych z kodu, co z kolei zmniejsza rozmiar kodu wytwarzanego po procesie.
Możemy również użyć innych preferowanych minifikatorów, dodając pole tablicy minimizer
w obiekcie optimization
. Przykładem jest użycie wtyczki Uglifyjs-webpack-plugin poniżej.
// webpack.config.js const Uglify = require("uglifyjs-webpack-plugin") module.exports = { optimization { minimize : true, minimizer : [ new Uglify({ cache : true, test: /\.js(\?.*)?$/i, }) ] } }
Powyżej uglifyjs-webpack-plugin
jest używany jako minifikator z dwiema dość ważnymi opcjami. Po pierwsze, włączenie cache
oznacza, że Uglify zminifikuje istniejące pliki tylko wtedy, gdy są to nowe zmiany, a opcja test
określa konkretne typy plików, które chcemy zminimalizować.
Uwaga: Wtyczka uglifyjs-webpack zawiera obszerną listę opcji dostępnych do użycia podczas minifikowania kodu za jego pomocą.
Mała prezentacja optymalizacji
Spróbujmy ręcznie zoptymalizować aplikację demonstracyjną, stosując niektóre pola w większym projekcie, aby zobaczyć różnicę. Chociaż nie będziemy zagłębiać się w optymalizację aplikacji, zobaczymy różnicę w rozmiarach pakietów między uruchomieniem pakietu webpack w trybie development
a uruchomieniem w trybie production
.
W tej wersji demonstracyjnej użyjemy aplikacji komputerowej zbudowanej przy użyciu Electron, która również używa React.js jako interfejsu użytkownika — wszystko w pakiecie z pakietem internetowym. Electron i React.js brzmią jak dość ciężka kombinacja i prawdopodobnie mogą wygenerować większy pakiet.
Uwaga : Jeśli po raz pierwszy uczysz się o Electronie , ten artykuł daje dobry wgląd w to, czym jest Electron i jak możesz go używać do tworzenia wieloplatformowych aplikacji komputerowych.
Aby wypróbować demo lokalnie, sklonuj aplikację z repozytorium GitHub i zainstaluj zależności za pomocą poniższych poleceń.
# clone repository git clone https://github.com/vickywane/webpack-react-demo.git # change directory cd demo-electron-react-webpack # install dependencies npm install
Aplikacja komputerowa jest dość prosta i składa się z jednej strony stylizowanej przy użyciu styled-components. Po uruchomieniu aplikacji komputerowej za pomocą polecenia yarn start
, pojedyncza strona wyświetla listę obrazów pobranych z CDN, jak pokazano poniżej.
Najpierw utwórzmy pakiet programistyczny tej aplikacji bez ręcznej optymalizacji, aby przeanalizować ostateczny rozmiar pakietu.
Uruchomienie yarn build:dev
z terminala w katalogu projektu spowoduje utworzenie pakietu programistycznego. Dodatkowo wydrukuje na twoim terminalu następujące statystyki:
Polecenie pokaże nam statystyki całej kompilacji i wyemitowanych pakunków.
Zwróć uwagę, że fragment mainRenderer.js
ma 1,11 MB (około 1,16 MB). mainRenderer
jest punktem wejścia dla aplikacji Electron.
Następnie dodajmy uglifyjs-webpack-plugin jako zainstalowaną wtyczkę w pliku webpack.base.config.js
w celu minimalizacji kodu.
// webpack.base.config.js const Uglifyjs = require("uglifyjs-webpack-plugin") module.exports = { plugins : [ new Uglifyjs({ cache : true }) ] }
Na koniec uruchommy pakiet aplikacji z webpackiem w trybie production
. Uruchomienie polecenia yarn build:prod
z terminala spowoduje przesłanie poniższych danych do terminala.
Zanotuj tym razem fragment mainRenderer
. Spadła do ogromnych 182 kibibajtów (około 186 KB), a to ponad 80% wielkości fragmentu mainRenderer
emitowanego wcześniej!
Zobrazujmy dalej emitowane paczki za pomocą analizatora webpack-bundler. Zainstaluj wtyczkę za pomocą polecenia yarn add webpack-bundle-analyzer
i zmodyfikuj plik webpack.base.config.js
, aby zawierał poniższy kod, który dodaje wtyczkę.
// webpack.base.config.js const Uglifyjs = require("uglifyjs-webpack-plugin"); const BundleAnalyzerPlugin = require("webpack-bundle-analyzer"); .BundleAnalyzerPlugin; const config = { plugins: [ new Uglifyjs({ cache : true }), new BundleAnalyzerPlugin(), ] }; module.exports = config;
Uruchom yarn build:prod
ze swojego terminala, aby aplikacja została ponownie spakowana. Domyślnie webpack-bundle-analyzer uruchomi serwer HTTP, który udostępnia wizualizowany przegląd pakietów w Twojej przeglądarce.
Na powyższym obrazku widzimy wizualną reprezentację emitowanego pakietu i rozmiarów plików w pakiecie. Na wizualizacji możemy zaobserwować, że w folderze node_modules
największym plikiem jest react-dom.production.min.js
, a następnie stylis.min.js
.
Korzystając z rozmiarów plików zwizualizowanych przez analizator, będziemy mieli lepsze wyobrażenie o tym, jaki zainstalowany pakiet wnosi większą część pakietu. Możemy wtedy poszukać sposobów na zoptymalizowanie go lub zastąpienie go lżejszym opakowaniem.
Uwaga: Dokumentacja wtyczki webpack-analyzer-plugin wymienia inne dostępne sposoby wyświetlania analizy utworzonej z wyemitowanych pakunków.
Społeczność webpack
Jedną z mocnych stron webpack jest duża społeczność programistów, którzy za nim stoją, co przydało się programistom wypróbowującym webpack po raz pierwszy. Podobnie jak w tym artykule, istnieje kilka artykułów, przewodników i zasobów z dokumentacją, która służy jako świetny przewodnik podczas korzystania z webpacka.
Na przykład przewodnik Build Performance z bloga webpack zawiera wskazówki dotyczące optymalizacji kompilacji webpacków, a studium przypadku Slacka (choć nieco stare) wyjaśnia, w jaki sposób webpack został zoptymalizowany w Slack.
W kilku zasobach społeczności wyjaśniono części dokumentacji pakietu webpack, udostępniając przykładowe projekty demonstracyjne pokazujące, w jaki sposób wykorzystywane są funkcje pakietu webpack. Przykładem jest artykuł na temat federacji modułów Webpack 5, który wyjaśnia, w jaki sposób nowa funkcja federacji modułów webpack jest używana w aplikacji React.
Streszczenie
Po siedmiu latach swojego istnienia, webpack naprawdę udowodnił, że jest ważną częścią łańcucha narzędzi JavaScript używanego w wielu projektach. Ten artykuł daje jedynie wgląd w to, co można osiągnąć dzięki elastycznej i rozszerzalnej naturze pakietu webpack.
Następnym razem, gdy będziesz musiał wybrać pakiet modułów dla swojej aplikacji, miejmy nadzieję, że lepiej zrozumiesz niektóre podstawowe koncepcje Webpack, problem, który rozwiązuje, a także kroki związane z konfiguracją plików konfiguracyjnych.
Dalsze czytanie na SmashingMag:
- Pakiet internetowy — szczegółowe wprowadzenie
- Zbuduj PWA z Webpackiem i Workbox
- Ustawianie TypeScriptu dla nowoczesnych projektów React za pomocą Webpack
- Jak wykorzystać maszyny: bycie produktywnym dzięki biegaczom zadań