Gulp, ahogy mi használjuk

Egy régebbi bejegyzésben már írtam arról, hogyan könnyítheti meg a Gulp.js használata a front-end fejlesztést, de leginkább csak bemutató jelleggel. Azóta eltelt majdnem két év és túl vagyunk számos nagy projekten, ahol gyakorlatban is használtuk az eszközt, és mára oda jutottunk, hogy el sem kezdünk nélküle fejleszteni. Megpróbálom összegyűjteni az eddigi tapasztalatainkat, és kifejteni, hogy milyen modulokat, miért és hogyan használunk.

Két év tapasztalatai vázlatpontokban

• kezdetekben leginkább WordPress projektekre húztuk praktikai okokból, azóta általánossá vált
• nem minden kolléga használta, mára minden projekt esetén alkalmazzuk
• ha egy kolléga először találkozik vele, nagyon hamar ráérez és átlátja a működését, a célját
• gyorsabb és kényelmesebb fejlesztést tett lehetővé
• megoldást nyújtott a verziókezelt projektjeink front-end fejlesztés során előkerülő kellemetlenségeire
• átlátható és fenntartható css kódot eredményezett
• elősegítette az újrafelhasználható css kódolást

Ahogy mi használjuk

Az alábbi linken elérhető egy, az általunk használt konfigokból: gulpfile.js
Azt hiszem, a kód magáért beszél, így nem is megyek bele, inkább a folyamatot írom le, hogy miért lett ilyen.

A gulp használatának kezdetén két fő megoldandó problémát tartottunk szem előtt:

• több fejlesztő is dolgozhasson conflictoktól mentesen ugyanazon projekt front-end kódjain (CSS, JavaScript)
• az oldalbetöltődési sebesség javítása érdekében optimalizáljuk a kódot (minify) és minimalizáljuk a requestek számát.

Az előbbi felvetésekre tökéletes megoldás volt, hogy logikai egységekre bontottuk az oldal által használt css-t (komponensek, tipográfia, grid, helper stb.), továbbá minden oldalhoz tartozó stíluslapok is külön fájlban kaptak helyet. Ezeket összefűztük adott sorrendben (kezdetben a fájlnév kapott prefixet, amivel meghatároztuk a sorrendet, így a reset.css-ből lett 00_reset.css), majd az eredmény minify után a style.min.css fájlban kötött ki. Ezeket elég egyszerűen meg tudtuk oldani bármilyen „getting started with gulp” tutorial alapján a gulp-concat, gulp-clean-css és gulp-uglify modulokkal.

Természetesen itt nem akartunk megállni, hiszen oly' sok helyen kiemelik, hogy a gulp használatával megspórolhatjuk a vendor prefixek használatát (gulp-autoprefixer) és elkezdtünk mindent SASS alapokon kezelni (gulp-sass), ennek eredményét az alábbi blogposztban olvashatod el.

Valljuk be, a fájlnevek számmal történő megjelölése nem a legelegánsabb mód a sorrend meghatározására, ráadásul megköveteli, hogy egy könyvtárban legyen minden scss fájl. Ennek kiküszöbölésére vezettük be a gulp-order modult, aminek segítségével meghatároztuk az összefűzés sorrendjét.

Extrák

A fent leírtak alapvetően ellátnak minden feladatot, amire szükség van, ám lehetett még szépíteni a dolgok működésén. A gulp-util modul lehetővé teszi az egyes üzenetek színes megjelenését, a kényelmesebb hibakezelést (három beep jelzi, ha valami nem tudott rendesen lefutni) és bekerült egy help task is, ami visszaadja a futtatható taskok listáját minimális magyarázattal.

Gyakran használunk svg ikonokat, amik kis méretűek, és hosszas mérlegelés után arra jutottunk, hogy bizonyos esetekben abszolút járható út és plusz szerverhívásoktól mentesíthetjük magunkat, ha ezek is bekerülnek a legenerált css fájlba base64 kódolással, amihez a gulp-css-base64 modult használtuk. Ezt persze nem használjuk minden esetben, paraméterrel (komment a szelektor után) letiltható.

Az összefűzés folyamatába beszúrtunk egy source map generálást is (gulp-sourcemaps), ami által a DevTools használata során könnyű beazonosítani, hogy az egyes szelektorok melyik forrásfájlban lettek definiálva, így nem kell keresgélni, ha valamihez hozzá akarunk nyúlni.

Mivel elég sok forrásfájlt kell lefordítani minden változáskor, így a folyamatosan futó „watcher” taskok kicsit máshogy működnek, mint az induláskor lefutóak. A szerver tehermentesítése érdekében csak a változott fájlokat dolgozza fel (scss->css) újra, amit a gulp-newer modul old meg.

Végszó

Egyértelműen ki tudom jelenteni, hogy a front-end task runnerek (esetünkben a Gulp.js) érezhető mértékben megkönnyítik a front-end fejlesztési munkát. Hamar bele lehet jönni a használatukba, és nem csak a robosztus projektek esetén érdemes alkalmazni őket. Elősegítik az újrafelhasználható és átlátható css kód írását, azon felül folyamatos visszajelzést is kapsz, ha valamit nem megfelelően csináltál (gulp-csslint), ezzel is a tiszta (css) kód felé haladva.
Rengeteg lehetőség és modul van még, amivel méginkább növelni lehet a hatékonyságot, az ftp deploy-on keresztül a nyelvi PO fájlok generálásán át a komplex forráskódelemzésig.
Ha eddig nem használtál task runnert, tégy egy próbát, nem fogsz csalódni!