Wieści z frontu, część 3 — konfiguracja webpacka

Przyszedł czas, żeby porozmawiać chwilę o konfiguracji webpacka.

Zakłądam że czytelnik zna javascript, oraz wie, czym jest node.js, potrafi korzystać z NPM i wie, czym jest plik package.json.

Poprzednim razem powiedzieliśmy sobie trochę o zaletach korzystania z webpacka. Ściągając nasz projekt startowy, możemy zobaczyć JAK to działa. Nie wiemy tylko DLACZEGO to działa.

Pora odpowiedzieć sobie na to pytanie. Oczywiście nie czytałem kodu źródłowego webpacka ( choć zapewne byłaby to wspaniała lektura do poduszki). Skupimy się więc na konfiguracji.

Zacznijmy od teorii i trzech podstawowych pojęć które nam będą potrzebne: PLUGIN i LOADER i BUNDLE.

Bundle

Przypomnijmy:

michal@cośtam:~/fakePath$ ls  -lh dist/
-rw-rw-r-- 1 michal michal 1,1M lis 12 10:08 build.js
-rw-rw-r-- 1 michal michal 1,5M lis 12 10:08 build.js.map
-rw-rw-r-- 1 michal michal     460 lis 12 10:08 index.html

To jest wynik budowania naszego projektu z poprzedniej części - to właśnie nazywamy naszą paczką , czyli BUNDLE . Jeden z głowy dwa zostały ;)

Plugin

Plugin to plugin. Inaczej wtyczka. Cały webpack skonstruowany jest na wtyczkach właśnie – to one zapewniają kolejne elementy całego procesu. Przykład lepszy niż 1000 słów. BrowserSyncPLugin uruchamia serwer z naszym zbudowanym projektem i synchronizuje przeglądarki. CopyWebpackPlugin dodaje nam możliwość bezpośredniego kopiowania plików.

Lista pluginów

Możliwości właściwie nie ograniczone. Pluginów jest bardzo dużo. Instalujemy je za pomocą "npm install --save-dev" i dokładamy do pliku konfiguracyjnego webpacka ( cierpliwości – dojdziemy do tego).

Loader

Zostały jeszcze LOADER-y. Jest to też pewien rodzaj pluginu, ale jego zadanie jest z góry określone. Loader ma za zadanie "wziąć" plik źródłowy ( obrazek, css, js, ts….. ) i przetworzyć go do bundle-a. (lub pozwolić kolejnemu loaderowi zadziałać). Loadery mogą być wykonywane łańcuchami. Na przykład Aby załadować plik css najpierw potrzbujemy loadera „css”, a następnie loadera „style”.

Lista loaderów

Konfiguracja

Dotarliśmy do miejsca gdzie możemy porozmawiać o konfiguracji ( mówiłem że w końcu nam się uda).

Podstawowy plik konfiguracyjny wygląda następująco:

var webpack = require('webpack');
module.exports = {
    context: __dirname + "/app",
    entry: "./index.ts",
    output: {
        path: __dirname + "/dist",
        filename: "bundle.js"
    }
}

Dodajemy do exportu obiekt konfiguracyjny, zapisujemy plik - powiedzmy jako webpack.js- a następnie uruchamiamy za pomocą polecenia:

"webpack --config webpack.js

oczywiście zbyt wiele tu nie skonfigurowaliśmy, ale podstawy mamy. Mamy plik wejściowy, oraz katalog dla naszej paczki.

Pluginy dodajemy do naszej konfiguracji jako tablica w odpowiedniej właściwości, oczywiście najpierw dodając zależność:

var BrowserSyncPlugin = require('browser-sync-webpack-plugin');
var webpack = require('webpack');
module.exports = {
    context: __dirname + "/app",
    entry: "./index.ts",
    output: {
        path: __dirname + "/dist",
        filename: "bundle.js"
    },
    plugins: [
         new BrowserSyncPlugin({
            host: 'localhost',
            port: 8080,
            server: {
                baseDir: 'dist'
            },
            ui: false,
            online: false,
            notify: false
        })/// TU KOLEJNE PLUGINY
    ]
}

Ot i mamy dodany serwer do naszego projektu. Podobnie postępujemy z innymi pluginami. Zauważ że jest to mechanizm bardzo elastyczny. pozwalający na dokładne skonfigurowanie naszej wtyczki.

Na stronach pluginu przeważnie możemy zobaczyć, co i jak możemy skonfigurować.

Ok. Wiemy jak dodać pluginy. Przyszła pora na loadery. Użyte loadery konfigurujemy w sekcji modlue.loaders. Wygląda to tak, że najczęściej dla jednego typu plików definiujemy łańcuch loaderów. Brzmi może dziwnie, ale w sumie jest to dość łatwe.

Pojedynczy wpis wygląd tak :

{
        test: /\.css$/,
        loader: 'style-loader!css-loader'
}

Ten konkretny mówi o tym że: wszystkie pliki o rozszerzeniu .css "potraktuj" loaderem css, a następnie loaderem style. Podsumowując w polu "test" mamy wyrażenie regularne, pod które "łapią" się nasze pliki a w polu loaders mamy łańcuch loaderów, które zostaną użyte w porządku od prawej do lewej. I ostatnia rzecz jaką musimy wiedzieć. Do konfiguracji przekazujemy tablice takich obiektów konfiguracyjnych:

var BrowserSyncPlugin = require('browser-sync-webpack-plugin');
var webpack = require('webpack');
module.exports = {
    context: __dirname + "/app",
    entry: "./index.ts",
    output: {
        path: __dirname + "/dist",
        filename: "bundle.js"
    },
    plugins: [
         new BrowserSyncPlugin({
            host: 'localhost',
            port: 8080,
            server: {
                baseDir: 'dist'
            },
            ui: false,
            online: false,
            notify: false
        })
    ], 
    module:{
        loaders: [
                 {test: /\.ts(x?)$/, loader: 'ts-loader'},
    {
        test: /\.css$/,
        loader: 'style-loader!css-loader'
    },
    {
        test: /\.scss$/,
        loader: 'style!css!resolve-url!sass?sourceMap'
    }, {
        test: /\.tpl.html$/, 
        exclude: /node_modules/,
        loader: 'html'
    }, {
        test: /\.woff(2)?(\?v=[0-9]\.[0-9]\.[0-9])?$/,
        loader: 'url-loader?limit=10000&mimetype=application/font-woff'
    }, {
        test: /\.(ttf|eot|svg)(\?v=[0-9]\.[0-9]\.[0-9])?$/,
        loader: 'file-loader'
    }, {
        test: /\.jpg$/,
        exclude: /node_modules/,
        loader: 'file'
    }, {
        test: /\.png$/,
        exclude: /node_modules/,
        loader: 'url'
    }
        ]
    }
}

Teraz webpack "WIE", że jeśli będziesz dołączał plik jpg, należy użyć loadera "file-loader", a jeśli będzie to plik css należy najpierw użyć loadera css, a następnie loadera style.

I w zasadzie gotowe. nasza konfiguracja jest kompletna.

Warto sobie wydzielić konfiguracje loaderów do osobnego pliku, oraz przygotować oddzielne konfiguracje dla paczki "produkcyjnej" oraz dla celów deweloperskich. Dlaczego? Na "devie" nie interesuje nas na przykład tak bardzo optymalizacja wielkości paczki , na "prodzie" nie potrzebujemy serwera itd.

Ostatnią rzeczą jaką zrobimy to konfiguracja npma, żeby uruchamiać webpacka zgodnie z konwencją, czyli poprzez polecenie npm start.

w tym celu w pliku package.json w sekcji scipts dodamy sobie odpowiednie wywołania.

"scripts": {
    "start": "webpack --config webpack/webpack.dev.js --watch --NODE_ENV=
    "build": "webpack --config webpack/webpack.build.js --NODE_ENV=production",
}

I to by było na tyle. Przykłady konfiguracji oczywiście znajdziemy w projekcie, który jest punktem wyjścia dla tej serii: GITHUB

No i do następnego!