Webpack — the module bundler | 3. část (+ yarn)
Webpack se stal v poslední době celkem skloňovanou technologií a často je srovnávan s dalšími utilitami jako je Gulp nebo Grunt. V tomto a několika dalších článcích se snažím vysvětlit princip a filosofii Webpacku a shrnout pár případů, kdy chceme a nechceme Webpack používat a jak jej používat.
Články vychází z textu, který jsem sepsal k ukázkovým konfiguracím Webpacku na Githubu, a které vznikly v rámci vzdělávacích meetingů u nás v Ackee ❤.
Module bundler versus task runner
V přechozích dvou článcích jsem se věnoval filosofii a konfiguraci Webpacku. Nyní by mělo být jasné, co je Webpack a k čemu se používá, přesto bych rád vysvětlil rozdíl mezi Webpackem a utilitami jako je Gulp nebo Grunt, se kterými je často srovnáván.
Gulp a Grunt jsou task runnery. Používají se k automatizaci úloh, které uživatel definuje pomocí programování nebo konfigurace (viz. dokumentace http://gulpjs.com/ a https://gruntjs.com/). Mezi úlohy může patřit kompilace, transpilace, minifikace, linting, testování atd. Důležité však je, že každá úloha pracuje s jedním konkrétním assetem (CSS, JavaScript atd.) a je na programátorovi, aby zajistil, že bude výsledek fungovat, tj. že budou například správně nastavené cesty k obrázkům.
Jak bylo zmíněno v předchozích článcích, Webpack je primárně utilita pracující s JavaScriptem a umožňuje psát modulární kód, který pro prohlížeč zabalí do balíčku. Webpack navíc svou filosofií dovoluje do JavaScriptového kódu přidávat i jiné druhy assetů a poté je pomocí loaderů a pluginů zpracovat. Z tohoto pohledu je spuštění Webpacku jedna konkrétní úloha.
Gulp ani Grunt nezkoumají kód, který jim je předán, jen nad ním provedou definované úlohy. Narozdíl od nich Webpack kód analyzuje a podle konfigurace jej upravuje a zpracovává.
To je tedy hlavní rozdíl. Webpack je konkrétní úloha spuštěná nad JavaScriptovým kódem. Je to podobné, jako když pustíte úlohu prosass kompiler, jen malinko složitější, protože dovoluje komplexnější transformace nad předaným kódem.
Kdy použít Webpack
Webpack se hodí pro několik případů použití. Tím, že je primárně určen pro práci s JavaScriptem, je vhodné jej takto používat. Kdy tedy použít Webpack?
- Pokud chcete psát modulární JavaScriptový kód, který bude umět zpracovat prohlížeč.
- Pokud chcete používat standarty JavaScriptu, které ještě nejsou implementovány (ES6+).
- Pokud píšete SPA například v Reactu, pak se Webpack přímo vybízí.
- Pokud píšete MPA a chcete psát moderní kód atd.
Zatím jsem zmínil pouze JavaScript, protože ostatní assety by měly být, dle mého názoru, brány v úvahu, jen pokud budete používat Webpack pro JavaScript, protože je do JavaScriptu budete muset importovat. Nedává smysl používat Webpack na SASS, pokud projekt obsahuje pouze SASS a CSS. To radši pusťe pouze sass --watch sass:css .
Já osobně používám Webpack neustále, ať píšu jen drobné kusy js kódu či velký projekt, protože mi dovoluje psát čistý, čitelný a moderní kód a navíc jej bez velké námahy rovnou obfuskuje.
Jelikož Webpack používám pravidelně, rovnou mám přidané loadery pro SASS a PostCSS a tím pádem mohu psát i moderní StyleSheety.
Přidanou hodnotou je i optimalizace dalších assetů jako jsou obrázky a fonty.
Má smysl používat task runnery s Webpackem?
Ano, má. Pokud používáte například Gulp a chcete přidat do svého projektu moderní modulovatelný JavaScriptový kód, tak nevidím důvod Webpack nepoužít, protože existuje například plugin do Gulpu, který dovoluje spouštět Webpack jako úlohu.
Pokud se vám navíc nelíbí importování SASSu do JavaScriptu, tak v případě použití Webpacku s Gulpem můžete oddělit transpilaci SASSu do vlastní úlohy.
Ale
Jak bylo zmíněno výše, patří mezi úlohy, které provádí task runnery, například minifikace, transpilace, linting nebo testování. To umí Webpack při troše konfigurace také, tudíž není nutné používat Webpack s task runnery.
Stačí pouze spustit napříkladexport NODE_ENV=production; webpack --progress --config webpack.config.js nebo přidat výše uvedený příkaz do package.json a pustit yarn run deploy.proda výsledek může být stejný jako s task runnerem. Je pouze na vás, jaké řešení vám více vyhovuje nebo lépe zapadá do vaší firemní dev flow.
A ještě dodatek …
Používejte Yarn
Situaci, kdy v při vývoji funguje celý projekt jak má, ale při nasazení do produkce pomocí CI najednou nefunguje nic, jsem zažil mnohokrát. Skoro vždy za to mohly balíčky nainstalované z NPM.
Důvod je prostý: při nasazení přes CI se instalují balíčky podle verzí uvedených v package.json, což může způsobit nainstalování novějšího balíčku, než který máte akuálně u sebe a všechno přestane fungovat. Řešení? Yarn.
Yarn je balíčkovací systém pro Node.js. Jeden takový už máme: npm. Yarn, stejně jako npm, funguje nad NPM repository a používá package.json. To znamená, že s ním nainstalujete to samé, co s npm. Proč jej tedy používat? Má trochu jinou filosofii, jiné příkazy, ale hlavně má lockfile.
Pokud pustíte yarn install a existuje vedle package.json i soubor yarn.lock, pak se neinstalují balíčky podle package.json, ale podle yarn.lock. Zde jsou zamklé verze z vaší instalace, což znamená, že při CI se nainstalují přesně ty samé balíčky, jako máte vy. Navíc, pokud na projektu pracuje více lidí, mají všichni stejné verze balíčků a všem by měl projekt fungovat stejně.
Jedná se o funkcionalitu, kterou má třeba composer pro PHP už dávno, v npm bohužel chybí.
Yarn navíc tvrdí, že je rychlejší než npm a také, že umí pracovat v offline módu, což podle mě není tak velké plus, jako zmíněný lockfile.
Používejte yarn, zjednoduší vám život!
V dalším článku
Webpack chuťovčičky: jak vyčlenit vendory z balíčků, jak fungují základní loadery, produkční vs. development konfigurace, development.
