Projektuppbyggnad beroende på klunk. Bygg fronten på fingrarna med Gulp. Kopiera startpaketet till projektet

13.04.2022

I den här artikeln kommer vi att överväga ett exempel på en Gulp-miljö som kan användas för bekväm front-end-utveckling av ett webbprojekt. Detta exempel konfigurerad som standard för att skapa webbplatser och webbapplikationer baserade på Bootstrap 4-ramverket.

Projektet som behandlas i den här artikeln finns på Github på: https://github.com/itchief/gulp-project-bootstrap-4

Video för den här artikeln:

Instruktioner för installation av Gulp-miljön

För att skapa en miljö måste du ha följande program installerade:

  • "Node.js" (du kan ladda ner installationsprogrammet "Node.js" för ditt operativsystem från den här sidan; projektet kräver minst version 10 );
  • "Gulp" (Du kan installera Gulp genom att köra följande kommando i konsolen: npm install -g gulp-cli).

Nästa steg är att installera npm-paket och deras beroenden. För att göra detta, i konsolen (bör finnas i projektets rotkatalog), måste du köra kommandot:

npm installera

Detta kommando kommer att installera alla paket som behövs både för själva miljöarbetet och för frontend. npm utför dessa åtgärder enligt instruktionerna skrivna i filen "package.json".

När du använder den första versionen av projektet (1.0.0), som använder Bower-pakethanteraren, måste du köra ett annat kommando:

Bower installation

Detta program kommer att installera gränssnittspaketen som anges i filen "bower.json".

Hur använder man Gulp-miljön?

Öppna en kommandotolk (sökvägen ska peka till projektets rotmapp) och skriv gulp (normalt läge):

Efter att ha angett detta kommando kommer standarduppgiften att starta, d.v.s. "standard". Denna uppgift kommer i sin tur att köra en rad andra uppgifter: "bygga", "webbserver" och "bevaka".

Uppgiften "bygga" kommer att bygga projektet för produktion (dvs. det kommer att köra "clean:build", "html:build", "css:build", "js:build", "fonts:build" och "image:build "). Dessa uppgifter kommer att placera de resulterande projektfilerna i mappen "tillgångar/bygga".

Uppgiften "webserver" är utformad för att köra en lokal webbserver med "live reload" av sidor i webbläsaren. Med den kan du mycket enkelt se projektet och utföra dess testning.

Uppgiften "bevaka" används för att hålla reda på ändringar av källfiler i mappen "tillgångar/källa" och köra olika uppgifter om de inträffar. Med andra ord låter det dig automatiskt köra de nödvändiga uppgifterna och hålla de resulterande filerna (innehållet i mappen "tillgångar/bygga") uppdaterade.


Dessutom kan du utföra en selektiv (oberoende) montering av en eller annan del av projektet.

Till exempel, för att bara bygga CSS för en del av webbplatsen, räcker det med att ange kommandot:

gulp css:build

Lista över andra uppgifter:

gulp clean:build // för att rensa upp katalogen "assets/build" gulp html:build // för att bygga HTML-filer gulp js:build // för att bygga JS-filer gulp fonts:build // för att bygga typsnitt gulp image:build / / till monteringsbild

Beskrivning av Gulp-miljön

I det här avsnittet kommer vi att analysera:

  • de viktigaste verktygen och filstrukturen för Gulp-miljön;
  • hur Bootstrap-källor är anslutna till projektet och hur de är konfigurerade;
  • hur man självständigt (från grunden) initierar Gulp-projektet och installerar beroenden (utan att använda det färdiga paketet.json)
  • hur man initierar Bower och installerar gränssnittspaket från början (utan att använda färdiga "bower.json"*);
  • innehållet i Gulp-projektbyggarfilen (gulpfile.js)

* Bower-pakethanteraren har inte använts i projektet sedan version 2.0.0.

Lista över verktyg

Miljön avsedd för utveckling av ett front-end-projekt (webbplats) är byggd på basis av följande verktyg:

  • Node.js (miljön där miljön kommer att köras);
  • npm (pakethanteraren ingår i Node.js; kommer att användas för att ladda Gulp, plugins och front-end-paket)
  • jQuery, Popover, Bootstrap (paket som kommer att användas för att bygga css- och js-delarna av webbplatsen);
  • Gulp och dess plugins (kommer att användas för att bygga projektet och utföra andra webbuppgifter).

I de första versionerna av projektet användes Bower-pakethanteraren dessutom. Det användes för att ladda biblioteken jQuery, Popover och Bootstrap. I projektversioner från 2.0.0 laddas dessa bibliotek med npm.

Gulp projektfilstruktur

Filstrukturen för ett projekt kan organiseras på olika sätt. Detta kan bero både på en viss utvecklares preferenser och på projektet för vilket det skapas.

I den här artikeln kommer vi att följa följande struktur:

Mappen "tillgångar" och filerna "gulpfile.js", "package.json" finns i roten av projektet. Filen "gulpfile.js" kommer att innehålla uppgifter för byggaren av Gulp-projektet.

Den första versionen av projektet använde också filerna ".bowerrc" och "bower.json". Filen "bower.json" är konfigurationsfilen för Bower-hanteraren, baserat på vilken de nödvändiga front-end-paketen fastställdes för laddning. I det här projektet användes det för att ladda Bootstrap, jQuery och Popper.

"Assets"-mappen innehåller två mappar: "src" (för källfiler) och "build" (för färdiga filer; Gulp-byggaren lägger dem i den här mappen). Mappen "src" innehåller katalogerna "fonts" (för typsnitt), "img" (för källbilder), "js" (för js-filer), "style" (för stilar) och "mall" (för HTML-fragment) och filen "index.html".

I den första versionen av projektet innehöll mappen "src" fortfarande katalogen "bower_components". Den var avsedd för komponenter som laddades med Bower. Det finns inte i den nuvarande versionen.

"js"-katalogen innehåller två filer: "main.js" och "my.js". Filen "my.js" används för att skriva dina egna skript, och "main.js" används för att definiera listan över filer vars innehåll måste inkluderas i den slutliga js-filen. Den sista filen är filen som ska vara utdata (i "bygg"-katalogen).

Katalogen "stil" är reserverad för stilar. Den här katalogen innehåller tre filer: "main.scss" (innehåller en lista över filer vars innehåll måste inkluderas i den slutliga stilfilen), "my.scss" (används för att skriva dina stilar) och "variables.scss" (innehåller SCSS variabler, med vilka vi kommer att ändra stilarna för Bootstrap 4, och även använda den för att skapa våra variabler).

Filen "index.html" är huvudsidan för projektet som skapas. Förutom "index.html" kan du lägga till andra html-sidor s.

Katalogen "mall" är avsedd för att placera fragment av HTML-sidor i den. Du kan till exempel skapa "head.html"- och "footer.html"-filer i den här katalogen och importera deras innehåll (med syntaxen //= path_to_file) till flera sidor samtidigt. Detta kommer att göra det lättare att skapa och redigera HTML-sidor, eftersom. enskilda delar av sidorna kommer redan att finnas i separata filer.

Ansluta Bootstrap 4-källor till projektet och ställa in dem

Existera olika sätt ansluta Bootstrap 4-ramverket till projektet, samt alternativ för att arbeta med det.

Det mest flexibla alternativet är att använda källkoder. I det här fallet, inte bara kan det är väldigt enkelt att ändra standardstilarna för Bootstrap, men också för att ansluta till projektet endast de klasser och komponenter som kommer att användas i den.

Bootstrap 4 CSS Styles Källkodade i SCSS och representeras av ett stort antal små filer.

Lista över SCSS-filer (finns i katalogen "node_modules/bootstrap/scss/"): "functions.scss", "variables.scss", "mixins.scss", "variables.scss", "print.scss", "reboot . scss", "type.scss", "images.scss", "code.scss", "grid.scss", "tables.scss", "forms.scss", "buttons.scss", "transitions.scss" " , "dropdown.scss" osv.

Varje sådan fil utför antingen en specifik tjänsteuppgift eller är ansvarig för att utforma en specifik funktion hos ett ramverk eller en komponent. SCSS-filer har kortfattade och begripliga namn. Genom att bara använda dem kan du ganska exakt förstå syftet med var och en av dem.

Anpassning eller ändring av standardstilarna för Bootstrap 4 är klar genom att omdefiniera värdena för SCSS-variabler. Alla SCSS-variabler är samlade på ett ställe för bekvämlighet (i filen "variables.scss"). Men det är önskvärt att omdefiniera deras värden, naturligtvis, inte i den här filen, utan i din egen (till exempel med samma namn "variables.scss", men ligger i "assets/style/variables.scss").

Till exempel att ändra temafärgen Framgång och fara, görs genom att ändra värdena för variablerna $green och $red:

// Åsidosätter standardvärdena för Bootstrap 4-variabler $red: #cc2eaa; $grön: #2ecc71;

notera att efter att ha kopierat Bootstrap 4-variablerna till din CSS-fil ("assets/style/variables.scss"), måste de vara otaggade! default .

!default-etiketten är till för att ställa in en SCSS-variabel till ett standardvärde. Om SCSS-variabeln redan har ett värde, kommer det nya värdet, om det anges med !default-nyckeln, inte att ställas in.

Att specificera vilka Bootstrap 4-käll-SCSS-filer som ska inkluderas i kompileringen till CSS och vilka som inte ska göras via SCSS-filen "assets/style/main.scss". Med andra ord är det innehållet i den här filen som kommer att avgöra vilken uppsättning stilar som kommer att kopplas till webbsidan efter kompilering.

Dessutom är filerna "assets/style/variables.scss" (för att åsidosätta Bootstrap-variabler) och "assets/style/my.scss" (för att skapa dina egna stilar) också kopplade till denna fil.

Innehållet i filen "main.scss" (exempel):

// Åsidosätt standardvariablerna för Bootstrap 4 och definiera dina egna @import "variabler"; // Inkludera de nödvändiga Bootstrap 4 SCSS-källorna @import "../../../node_modules/bootstrap/scss/_functions"; @import "../../../node_modules/bootstrap/scss/_variables"; @import "../../../node_modules/bootstrap/scss/_mixins"; @import "../../../node_modules/bootstrap/scss/_root"; @import "../../../node_modules/bootstrap/scss/_reboot"; @import "../../../node_modules/bootstrap/scss/_type"; @import "../../../node_modules/bootstrap/scss/_images"; @import "../../../node_modules/bootstrap/scss/_code"; @import "../../../node_modules/bootstrap/scss/_grid"; @import "../../../node_modules/bootstrap/scss/_tables"; @import "../../../node_modules/bootstrap/scss/_forms"; @import "../../../node_modules/bootstrap/scss/_buttons"; @import "../../../node_modules/bootstrap/scss/_transitions"; @import "../../../node_modules/bootstrap/scss/_dropdown"; @import "../../../node_modules/bootstrap/scss/_button-group"; @import "../../../node_modules/bootstrap/scss/_input-group"; @import "../../../node_modules/bootstrap/scss/_custom-forms"; @import "../../../node_modules/bootstrap/scss/_nav"; @import "../../../node_modules/bootstrap/scss/_navbar"; @import "../../../node_modules/bootstrap/scss/_card"; @import "../../../node_modules/bootstrap/scss/_breadcrumb"; @import "../../../node_modules/bootstrap/scss/_pagination"; @import "../../../node_modules/bootstrap/scss/_badge"; @import "../../../node_modules/bootstrap/scss/_jumbotron"; @import "../../../node_modules/bootstrap/scss/_alert"; @import "../../../node_modules/bootstrap/scss/_progress"; @import "../../../node_modules/bootstrap/scss/_media"; @import "../../../node_modules/bootstrap/scss/_list-group"; @import "../../../node_modules/bootstrap/scss/_close"; @import "../../../node_modules/bootstrap/scss/_toasts"; @import "../../../node_modules/bootstrap/scss/_modal"; @import "../../../node_modules/bootstrap/scss/_tooltip"; @import "../../../node_modules/bootstrap/scss/_popover"; @import "../../../node_modules/bootstrap/scss/_carousel"; @import "../../../node_modules/bootstrap/scss/_spinners"; @import "../../../node_modules/bootstrap/scss/_utilities"; @import "../../../node_modules/bootstrap/scss/_print"; // Inkludera dina SCSS-filer @import "my";

Dessutom kräver vissa Bootstrap 4-komponenter även JavaScript-kod för att fungera.

Lista över Bootstrap 4 js-filer (finns i katalogen "node_modules/bootstrap/js/dist/"): "util.js", "alert.js", "button.js", "carousel.js", "collapse.js ", "dropdown.js", "modal.js", "tooltip.js", "popover.js", "scrollspy.js", "tab.js" och "toast.js".

Att avgöra vilka js-filer i Bootstrap 4-ramverket som måste inkluderas i projektets slutliga js-fil, och vilka som inte är det, görs genom "main.js".

Importerar önskade filer i den resulterande build/main.js görs genom följande konstruktion:

//= sökväg_till_fil

Utför denna åtgärd kommer Gulp plugin "gulp-rigger". Hur man installerar och ansluter den kommer att beskrivas nedan.

Du kan också importera jQuery, Popper (krävs för driften av komponenterna Dropdown, Tooltip och Popover) och, om nödvändigt, dina egna js-filer till den här filen.

Innehållet i filen "main.js" (exempel):

// Importera jQuery //= ../../../node_modules/jquery/dist/jquery.js // Importera Popper //= ../../../node_modules/popper.js/dist/umd /popper.js // Importera de nödvändiga Bootstrap 4 js-filerna //= ../../../node_modules/bootstrap/js/dist/util.js //= ../../../node_modules/ bootstrap/js/dist/alert.js //= ../../../node_modules/bootstrap/js/dist/button.js //= ../../../node_modules/bootstrap/js/ dist/carousel.js //= ../../../node_modules/bootstrap/js/dist/collapse.js //= ../../../node_modules/bootstrap/js/dist/dropdown. js //= ../../../node_modules/bootstrap/js/dist/modal.js //= ../../../node_modules/bootstrap/js/dist/tooltip.js //= ../../../node_modules/bootstrap/js/dist/popover.js //= ../../../node_modules/bootstrap/js/dist/scrollspy.js //= ../. ./../node_modules/bootstrap/js/dist/tab.js //= ../../../node_modules/bootstrap/js/dist/toast.js // Importera andra js-filer //= min . js

Hur initierar man ett Gulp-projekt och installerar beroenden från början?

Utvecklingen av ett projekt börjar vanligtvis med skapandet av en "package.json"-fil (manifest).

Filen "package.json" kommer att innehålla allmän information om projektet (namn, version, beskrivning, författarens namn, etc.), samt information om de paket som detta projekt är beroende av.

För att skapa ett manifest måste du gå till rotmappen för projektet och ange kommandot:

npm init

Efter att ha angett kommandot måste du svara på följande frågor:

  • projektnamn (namn) - "bootstrap-4";
  • versionsnummer (version) – "2.0.0";
  • beskrivning (beskrivning) - "Starta projekt med användning av Bootstrap 4";
  • författare (författare) - "webbplats";
  • git repository (git repository) - "";
  • ingångspunkt, testkommando, licens, nyckelord(sökord) – standardvärden.

På frågan "Är det här ok?" svara "ja" eller tryck på Enter .

Som ett resultat kommer filen "package.json" att visas i projektets rotmapp.

Låt oss nu installera paketen som vi kommer att använda i projektet med följande kommando:

npm installera paketnamn --save-dev // installera paketet, med information om det automatiskt lagt till i avsnittet "devDependencies" i filen "package.json" npm install package_name --save-prod // installera paketet, med information om det , läggs automatiskt till i avsnittet "beroenden" i filen "package.json".

Nyckeln "--save-dev" eller "--save-prod" bestämmer vilken del av filen "package.json" som kommer att innehålla information om den.

Lista över paket som ska användas i projektet:

npm installera gulp --save-dev // installera gulp npm installera browser-sync --save-dev // installera webbläsar-sync npm installera gulp-autoprefixer --save-dev // installera gulp-autoprefixer npm installera gulp-cache - -save-dev // installera gulp-cache npm installera gulp-clean-css --save-dev // installera gulp-clean-css npm installera gulp-rimraf --save-dev // installera gulp-clean-css npm install gulp-imagemin --save-dev // installera gulp-imagemin npm installera gulp-plumber --save-dev // installera gulp-plumber npm installera gulp-rigger --save-dev // installera gulp-rigger npm installera gulp- sass --save-dev // installera gulp-sass npm installera gulp-sourcemaps --save-dev // installera gulp-sourcemaps npm installera gulp-uglify --save-dev // installera gulp-uglify npm installera imagemin-jpeg- recompress --save-dev // installera imagemin-jpeg-recompress npm installera imagemin-pngquant --save-dev // installera imagemin-pngquant npm installera gulp-rename --save-dev // installera imagemin-pngquant npm installera jquery - -save-prod npm inst alla popper.js --save-prod npm installera bootstrap --save-prod

Efter installation av alla beroenden kommer filen package.json att ha följande innehåll:

( "name": "bootstrap-4", "version": "2.0..com/itchief/gulp-project-bootstrap-4.git" ), "dependencies": ( "jquery": "^3.4.1" , "popper.js": "^1.14.7", "bootstrap": "^4.3.1" ), "devDependencies": ( "browser-sync": "^2.26.7", "gulp": "^ 4.0.2", "gulp-autoprefixer": "^6.1.0", "gulp-cache": "^1.1.2", "gulp-clean-css": "^4.2.0", "gulp-rimraf ": "^0.2.2", "gulp-imagemin": "^6.0.0", "gulp-plumber": "^1.2.1", "gulp-rigger": "^0.5.8", "gulp -sass": "^4.0.2", "gulp-sourcemaps": "^2.6.5", "gulp-uglify": "^3.0.2", "imagemin-jpeg-recompress": "^6.0.0 ", "imagemin-pngquant": "^8.0.0", "gulp-rename": "^1.4.0") ) )

Hur initierar man Bower och installerar frontend-paket från början?

Låt oss definiera en mapp där Bower ska ladda ner paketen. För att göra detta, skapa en .bowerrc-fil och skriv in följande i den:

("katalog" : "tillgångar/src/bower_components/" )

Spara .bowerrc-filen. Nu kommer alla komponenter att laddas in i katalogen bower_components som finns i assets/src/ .

Låt oss initiera Bower (skapa en bower.json-manifestfil). Skapandet av filen bower.json kan göras med kommandot (i projektets rotmapp):

Bower init

Efter det måste du svara på följande frågor:

  • projektnamn (namn) - bootstrap-4;
  • beskrivning (beskrivning) - Starta projektet på Bootstrap 4 - webbplats;
  • författare (författare) - webbplats;
  • ställ in installerade komponenter som beroenden (ställ in för närvarande installerade komponenter som beroenden) - Y (Ja);
  • vill du markera detta paket som privat vilket förhindrar att det av misstag publiceras i registret - Y (Ja);
  • för resten av frågorna lämnar vi svaren som erbjuds av programmet som standard;

Dessa steg kommer att skapa en bower.json-fil.

Låt oss ladda Bootstrap 4 och paketen det beror på (Popper och jQuery) i vårt projekt med Bower.

För att göra detta, skriv in följande kommando i konsolen:

Bower installera bootstrap#v4.0.0-beta --save

Växeln -save krävs för att skriva paketinformationen till beroendesektionen i filen bower.json.

Som ett resultat kommer bower.json att ha följande innehåll:

( "name": "bootstrap-4", "description": "Starta projekt på Bootstrap 4 - webbplats", "authors": [ "webbplats" ], "license": "ISC", "keywords": , "hemsida ": "", "ignore": [ "**/.*", "node_modules", "bower_components", "assets/src/bower_components/", "test", "tests" ], "dependencies": ( " jquery": "^3.2.1", "bootstrap": "^v4.0.0-beta" ) )

Om du inte vill initiera Bower (bower.json) med kommandot bower init och installera paket manuellt, kan du helt enkelt skapa en bower.json-fil (med till exempel en filhanterare) och klistra in ovanstående textinnehåll i den . För att installera beroenden i projektet räcker det med att ange följande kommando:

Bower installation

Beskrivning av Gulp-projektbyggarfilen (gulpfile.js)

Alla åtgärder som utfördes innan detta var förberedande. All funktionalitet som den skapade miljön kommer att utföra kommer att bestämmas av filen "gulpfile.js".

Filen "gulpfile.js" är en lista med uppgifter.

De huvudsakliga uppgifterna som den här filen kommer att utföra:

  • samla flera stilfiler till en, kompilera den resulterande SCSS till CSS, lägga till autoprefix, minimera CSS och skapa en källkarta;
  • importera alla nödvändiga js-filer till en, minimera den här filen och skapa en källkarta;
  • insamling av html-fil, överföring av typsnitt, bearbetning (komprimering) av bilder och automatisk uppdatering av sidor genom Browser Sync.

Dessutom, för att inte köra dessa uppgifter när du ändrar källfilerna manuellt, låt oss skapa en annan "bevaknings"-uppgift. Det kommer att övervaka filändringar och köra vissa uppgifter automatiskt.

Filkod "gulpfile.js" (när du använder Gulp 4):

"använd strikt"; /* Sökvägar till källfiler (src), färdiga filer (build) och filer att titta på för ändringar (watch) */ var path = ( build: ( html: "assets/build/", js: "assets/build/ js/", css: "assets/build/css/", img: "assets/build/img/", fonts: "assets/build/fonts/" ), src: (html: "assets /src/*. html", js: "assets/src/js/main.js", stil: "assets/src/style/main.scss", img: "assets/src/img/**/*. *", fonts: "assets/src/fonts/**/*.*" ), watch: ( html: "assets/src/**/*.html", js: "assets/src/js/** /*.js" , css: "assets/src/style/**/*.scss", img: "assets/src/img/**/*.*", fonts: "assets/srs/fonts/* */*.* " ), clean: "./assets/build/*" ); /* serverinställningar */ var config = ( server: ( baseDir: "./assets/build" ), notify: false ); /* Inkludera gulp och plugins */ var gulp = require("gulp"), // Inkludera Gulp webbserver = require("browser-sync"), // Server för att köra och automatiskt uppdatera sidor plumber = require("gulp-plumber "), // modul för spårningsfel rigger = require("gulp-rigger"), // modul för att importera innehållet i en fil till en annan sourcemaps = require("gulp-sourcemaps"), // modul för att generera en karta av sass källfiler = require("gulp-sass"), // modul för att kompilera SASS (SCSS) till CSS autoprefixer = require("gulp-autoprefixer"), // modul för automatisk inställning av autoprefix cleanCSS = require("gulp- clean-css" ), // plugin för att minifiera CSS uglify = require("gulp-uglify"), // plugin för att minifiera JavaScript-cache = require("gulp-cache"), // plugin för cachning av imagemin = require(" gulp-imagemin" ), // plugin för att komprimera PNG-, JPEG-, GIF- och SVG-bilder jpegrecompress = require("imagemin-jpeg-recompress"), // plugin för jpeg-komprimering pngquant = require("imagemin-pngq uant"), // plugin för png-komprimering rimraf = require("gulp-rimraf"), // plugin för att ta bort filer och kataloger rename = require("gulp-rename"); /* uppgifter */ // starta servern gulp.task("webserver", funktion () ( webbserver(config); )); // build html gulp.task("html:build", funktion () ( return gulp.src(path.src.html) // välj alla html-filer i den angivna sökvägen. pipe(plumber()) // spåra fel . pipe(rigger()) // importera bilagor. pipe(gulp.dest(path.build.html)) // ladda upp färdiga filer. pipe(webserver.reload(( stream: true ))); // starta om servern ) ); // collect styles gulp.task("css:build", function () (retur gulp.src(path.src.style) // få main.scss .pipe(plumber()) // för att spåra errors.pipe( sourcemaps.init()) // initiera sourcemap .pipe(sass()) // scss -> css .pipe(autoprefixer()) // add prefixes.pipe(gulp.dest(path.build.css)) .pipe (rename(( suffix: ".min" ))) .pipe(cleanCSS()) // Minifiera CSS .pipe(sourcemaps.write(". /")) // skriv källkarta .pipe(gulp.dest(path.build.css)) // ladda upp till build .pipe(webserver.reload((stream: true ))); // starta om servern )); / / build js gulp.task("js:build", funktion () ( return gulp.src(path.src.js) // hämta main.js-filen .pipe(plumber()) // för felspårning.pipe ( rigger()) // importera alla specificerade filer till main.js .pipe(gulp.dest(path.build.js)) .pipe(rename(( suffix: ".min" ))) .pipe(sourcemaps.init ( )) //initialize sourcemap .pipe(uglify()) //minify js .pipe(sourcemaps.write("./")) //write sourcemap .pipe(gulp.dest(path.build.js)) / / lägg den färdiga filen. pipe(webserver.reload(( stream: true ))); // starta om servern )); // transfer fonts gulp.task("fonts:build", function () (retur gulp.src (sökväg. src.fonts) .pipe(gulp.dest(path.build.fonts)); )); // process images gulp.task("image:build", function () (retur gulp.src(path. src.img ) // sökväg med bildkällor. pipe(cache(imagemin([ // bildkomprimering i magemin.gifsicle(( interlaced: true )), jpegrecompress(( progressiv: true, max: 90, min: 80 )), pngquant(), imagemin.svgo(( plugins: [( removeViewBox: false )] )) ]) )) .pipe(gulp.dest(path.build.img)); // ladda upp färdiga filer )); // radera byggkatalog gulp.task("clean:build", function () (retur gulp.src(path.clean, (läs: false)) .pipe(rimraf()); )); // clear cache gulp.task("cache:clear", function () ( cache.clearAll(); )); // build gulp.task("build", gulp.series("clean:build", gulp.parallel("html:build", "css:build", "js:build", "fonts:build", " image:build"))); // kör uppgifter när filer ändras gulp.task("watch", function () ( gulp.watch(path.watch.html, gulp.series("html:build")); gulp.watch(path.watch.css , gulp.series("css:build")); gulp.watch(path.watch.js, gulp.series("js:build")); gulp.watch(path.watch.img, gulp.series(" image:build")); gulp.watch(path.watch.fonts, gulp.series("fonts:build")); )); // default task gulp.task("default", gulp.series("build", gulp.parallel("webserver","watch")));

Filkoden "gulpfile.js" innehåller kommentarer. Med hjälp av dem förklaras det vad det här eller det fragmentet av instruktioner utför.

Att skapa en uppgift i Gulp är väldigt enkelt:

// skapa en gulp-uppgift (nametask är namnet på uppgiften) gulp.task("nametask", function() ( // åtgärder som uppgiften ska utföra... ));

Uppgifter i gulp är byggda väldigt enkelt. Deras handlingsram kan i de flesta fall representeras enligt följande:

  • hämta data från källfiler;
  • bearbeta rådata med hjälp av gulp-plugins;
  • spara resultatet (filerna) i "build"-katalogen.

Om du använder Gulp 3, bör innehållet i filen "gulpfile.js" vara som följer:

"använd strikt"; /* alternativ för gulp-autoprefixer */ var autoprefixerList = [ "Chrome >= 45", "Firefox ESR", "Edge >= 12", "Explorer >= 10", "iOS >= 9", "Safari >= 9", "Android >= 4.4", "Opera >= 30" ]; /* Sökvägar till källfiler (src), färdiga filer (build) och filer att titta på för ändringar (watch) */ var path = ( build: ( html: "assets/build/", js: "assets/build/ js/", css: "assets/build/css/", img: "assets/build/img/", fonts: "assets/build/fonts/" ), src: (html: "assets /src/*. html", js: "assets/src/js/main.js", stil: "assets/src/style/main.scss", img: "assets/src/img/**/*. *", fonts: "assets/src/fonts/**/*.*" ), watch: ( html: "assets/src/**/*.html", js: "assets/src/js/** /*.js" , css: "assets/src/style/**/*.scss", img: "assets/src/img/**/*.*", fonts: "assets/srs/fonts/* */*.* " ), clean: "./assets/build/*" ); /* serverinställningar */ var config = ( server: ( baseDir: "./assets/build" ), notify: false ); /* Inkludera gulp och plugins */ var gulp = require("gulp"), // Inkludera Gulp webbserver = require("browser-sync"), // Server för att köra och automatiskt uppdatera sidor plumber = require("gulp-plumber "), // modul för spårningsfel rigger = require("gulp-rigger"), // modul för att importera innehållet i en fil till en annan sourcemaps = require("gulp-sourcemaps"), // modul för att generera en karta av sass källfiler = require("gulp-sass"), // modul för att kompilera SASS (SCSS) till CSS autoprefixer = require("gulp-autoprefixer"), // modul för automatisk inställning av autoprefix cleanCSS = require("gulp- clean-css" ), // plugin för att minifiera CSS uglify = require("gulp-uglify"), // plugin för att minifiera JavaScript-cache = require("gulp-cache"), // plugin för cachning av imagemin = require(" gulp-imagemin" ), // plugin för att komprimera PNG-, JPEG-, GIF- och SVG-bilder jpegrecompress = require("imagemin-jpeg-recompress"), // plugin för jpeg-komprimering pngquant = require("imagemin-pngq uant"), // plugin för png-komprimering rimraf = require("gulp-rimraf"), // plugin för att ta bort filer och kataloger rename = require("gulp-rename"); /* uppgifter */ // starta servern gulp.task("webserver", funktion () ( webbserver(config); )); // build html gulp.task("html:build", funktion () ( return gulp.src(path.src.html) // välj alla html-filer i den angivna sökvägen. pipe(plumber()) // spåra fel . pipe(rigger()) // importera bilagor. pipe(gulp.dest(path.build.html)) // ladda upp färdiga filer. pipe(webserver.reload(( stream: true ))); // starta om servern ) ); // collect styles gulp.task("css:build", function () (retur gulp.src(path.src.style) // få main.scss .pipe(plumber()) // för att spåra errors.pipe( sourcemaps.init()) // initiera sourcemap .pipe(sass()) // scss -> css .pipe(autoprefixer(( // lägg till prefix webbläsare: autoprefixerList ))) .pipe(gulp.dest(path.build. css)) .pipe(rename(( suffix: ".min" ))) .pipe(cleanCSS()) // Minifiera CSS .pipe(sourcemaps.write(". /")) // skriv källkarta .pipe(gulp.dest(path.build.css)) // ladda upp till build .pipe(webserver.reload((stream: true ))); // starta om servern )); / / build js gulp.task("js:build", funktion () ( return gulp.src(path.src.js) // hämta main.js-filen .pipe(plumber()) // för felspårning.pipe ( rigger()) // importera alla specificerade filer till main.js .pipe(gulp.dest(path.build.js)) .pipe(rename(( suffix: ".min" ))) .pipe(sourcemaps.init ( )) //initialize sourcemap .pipe(uglify()) //minify js .pipe(sourcemaps.write("./")) //write sourcemap .pipe(gulp.dest(path.build.js)) / / lägg den färdiga filen. pipe(webserver.reload(( stream: true ))); // starta om servern )); // transfer fonts gulp.task("fonts:build", function () (retur gulp.src (sökväg. src.fonts) .pipe(gulp.dest(path.build.fonts)); )); // process images gulp.task("image:build", function () (retur gulp.src(path. src.img ) // sökväg med bildkällor. pipe(cache(imagemin([ // bildkomprimering i magemin.gifsicle(( interlaced: true )), jpegrecompress(( progressiv: true, max: 90, min: 80 )), pngquant(), imagemin.svgo(( plugins: [( removeViewBox: false )] )) ]) )) .pipe(gulp.dest(path.build.img)); // ladda upp färdiga filer )); // radera byggkatalog gulp.task("clean:build", function () (retur gulp.src(path.clean, (läs: false)) .pipe(rimraf()); )); // clear cache gulp.task("cache:clear", function () ( cache.clearAll(); )); // build gulp.task("build", [ "clean:build", "html:build", "css:build", "js:build", "fonts:build", "image:build" ]); // kör uppgifter när filer ändras gulp.task("watch", function () ( gulp.watch(path.watch.html, ["html:build"]); gulp.watch(path.watch.css, [" css:build"]); gulp.watch(path.watch.js, ["js:build"]); gulp.watch(path.watch.img, ["image:build"]); gulp.watch(sökväg .watch.fonts, ["fonts:build"]); )); // default task gulp.task("default", [ "build", "webserver", "watch" ]);

På den tiden när anläggningarna var små, behövdes det inte en separat frontmontering. Volymen och komplexiteten för CSS och JS har dock ökat, och vyn där det är bekvämt att utveckla har blivit mycket annorlunda än vyn där du behöver visa resultatet för användaren. Uppgifter som sammanlänkning (limning) av filer, minimering av kod och till och med förkompilering dök upp. Resultatet av detta var specialiserade front-end-byggsystem, som vi kommer att prata om.

Naturligtvis, så snart behovet av montering blev påtagligt, började verktygen som användes av backend omedelbart krypa till frontend. Deras huvudsakliga problem och anledningen till att de för tillfället används allt mindre för front-end är att de helt inte är skräddarsydda för dess specifikationer, eftersom projektstrukturen, den använda tekniken och utvecklingscykeln är mycket beroende av projektets uppgifter och kan skilja sig avsevärt. Samma Ant, till exempel, har en utförlig syntax och är inte särskilt kapabel att göra saker som är nödvändiga för frontend: det finns väldigt få inbyggda uppgifter och den expanderar dåligt. Om vi ​​pratar om GNU-fabrikat, så är det mycket mer mångsidigt, eftersom det fungerar med skalkommandon. Bland nackdelarna är det nödvändigt att nämna den speciella syntaxen som behöver studeras vidare, behovet av att känna till skalet väl, samt tendensen att Makefilen snabbt blir mer komplex när monteringskraven ökar.

Låt oss titta på en medelstor webbplats med en standardstruktur och försöka lista de viktigaste byggstegen som den går igenom. Låt oss för enkelhetens skull anta att du inte bryr dig om att skapa olika JS-filer för olika sidor, utan du vill behålla några små filer i din utvecklingsmiljö för att stödja någon form av modularitet. Det brukar se ut ungefär så här:

/libs/ jquery.min.js underscore.min.js /js/ common.js carousel.js popups.js ....

Byggsystemet gör vanligtvis följande:

  • sammanfogar alla JS-filer till en (i rätt ordning, vi vill inte ladda våra skript före jQuery);
  • kontrollerar JS-koden för giltighet (till exempel med JSHint);
  • minimerar koden, fördunklar den vid behov (det vill säga gör den obegriplig);
  • sammanfogar CSS-filer (ordningen är också viktig här, eftersom egenskaper ofta omdefinieras);
  • minifiera CSS;
  • lägger filerna i en separat katalog, från vilken du inkluderar dem i din HTML.

Ofta detta enkel krets kompliceras av ytterligare krav: tester körs, CSS-förprocessorkod kompileras, bilder optimeras, mallar kompileras.

Alla dessa uppgifter, och ännu fler, kan lösas med moderna monteringsverktyg. Vi kommer att överväga de mest populära lösningarna som fungerar på Node.js-plattformen. Deras gemensamma fördel är ett tydligt språk som alla front-end-utvecklare kan (eller tror att de kan), ett initialt fokus på att lösa front-end-problem och en tydlig Node.js-miljö där du kanske redan håller på att utveckla din applikation.

Grymta

Grunt är det äldsta, viktigaste och mest populära byggverktyget. Nästan alla byggsystem vi har tittat på jämför sig själva med Grunt på ett eller annat sätt, och några har dykt upp som snabbare eller enklare alternativ till det. Trots detta har den ett par betydande nackdelar.

För det första, som många frontend-utvecklare påpekar, är Grunt talrik. För att sätta upp ett enkelt byggsystem behöver du en konfiguration för hundra rader. Men detta är i sig inte en sådan nackdel: konfigurationen är ganska lätt att läsa, och på grund av Grunts popularitet är det vanligtvis inte svårt att hitta en färdig konfiguration för en typisk uppgift.

För det andra utvecklades Grunt som en universell produkt, det vill säga på grundval av det kan du lösa nästan alla uppgifter som är kopplade till att bygga ett projekt. Det är coolt, men du måste betala för mångsidighet. Som nämnts mångsidighet och snabbhet. Jämfört med andra Node.js-byggsystem är Grunt märkbart långsammare och, mest frustrerande, tenderar det att sakta ner när projektet växer. Utan att gå in på detaljerna i Grunts arkitektur ligger anledningen i det faktum att varje gång du behöver bygga till exempel en JS-fil så bygger den om alla JS-filer. Du kan försöka påskynda byggprocessen genom att manuellt skriva de nödvändiga länkarna mellan filerna, men på ett projekt med ett komplext träd av filberoenden kan detta vara alltför komplicerat.

Trots allt detta har Grunt ett enormt ekosystem: hundratals plugins, tusentals projekt, miljarder utvecklare, det är allt. Det vill säga, inte bara är Grunt universell, utan också en plugin för din uppgift, troligen, har redan skrivits.

Sammanfattningsvis är Grunt ett utmärkt val för små till medelstora projekt, speciellt om du inte har satt upp några byggsystem tidigare. En enorm gemenskap, ett gäng plugins, tydlig dokumentation och till och med artiklar och rapporter på ryska för de olyckliga människor som inte kan leva utan det. Och naturligtvis, om Grunt i framtiden, av någon anledning, slutar att passa dig, kan du alltid byta till ett annat system utan dess brister.

klunk

Gulp är ett byggsystem som för närvarande utvecklas aktivt. Dess arkitektur är baserad på användningen av trådar i Node.js, vilket gör att du inte kan skriva temporära filer och mappar till disken. De främsta fördelarna med Gulp är konfigurationens snabbhet och korthet. Dessutom, om den första är obestridlig, uppnås korthet jämfört med Grunt helt enkelt på grund av dess olika struktur. Om du i Grunt-konfigurationen arbetar individuellt med plugins och konfigurerar var och en av dem, måste du i Gulp-konfigurationen beskriva processen som varje fil (eller uppsättning filer) måste gå igenom för att kunna byggas. Här är ett liveexempel på att kompilera SASS:

Gulp.task("styles", function() ( return gulp.src("styles/*.scss") .pipe(sass(( style: "expanded" ))) .pipe(rename((suffix: ".min) "))) .pipe(minifycss()) .pipe(gulp.dest("build/styles/css")); ));

På den första raden registrerar vi en uppgift för Gulp named styles . Sedan beskriver vi sekventiellt vad som behöver göras med var och en av filerna som matchar styles/*.scss-masken: kompilera SASS, lägg till .min i filnamnet, minifiera det, lägg det i den sista katalogen. Om vi ​​behöver göra något annat med den här filen lägger vi helt enkelt till det lämpliga kommandot, till exempel pipe (lägg till en kommentar med en ASCII-enhörning i början av filen) (jag hoppas att de äntligen gör ett plug-in för denna vardagliga uppgift). Jag gillar det här sättet att skriva en konfiguration mer: det beskriver bättre vad som verkligen händer med dina filer.

Naturligtvis, medan Gulp förlorar mot Grunt när det gäller antalet plugins, finns det plugins för många uppgifter. Med största sannolikhet kommer befintliga plugins att räcka för dig, och om något verkligen saknas kan du alltid skriva egna (skämtar bara). Det finns förresten ett gulp-grunt-paket som låter dig köra Grunt-uppgifter från Gulp om du verkligen behöver.

Om du gillar det här tillvägagångssättet för att bygga är hastigheten viktig och du behöver inte utföra specifika uppgifter för vilka det bara finns en plug-in för Grunt, då kan Gulp vara ett utmärkt val. På det här ögonblicket Gulp är fortfarande Grunts största konkurrent.

Broccoli

Det yngsta av de byggverktyg som övervägs är nu i själva verket under utveckling. Broccolli-utvecklarna döljer inte det faktum att de inspirerades av Gulp, men de anser att några av koncepten som ligger bakom det är felaktiga. Till exempel valde de att cachelagra alla mellanliggande byggresultat (implementerade av vart och ett av plugin-programmen) för att påskynda bygget, istället för att delvis bygga om endast de nödvändiga filerna. De gillade inte heller att Gulp fungerar bäst med att förvandla en fil till en final, det vill säga en efter en. För att förbättra prestandan för många-till-en-operationer utvecklar Gulp för närvarande ett komplext schema med skapandet av ett virtuellt filsystem, vilket för utvecklarna av Broccolli verkar vara en onödig komplikation och en manifestation av de ursprungliga konceptens svaghet av Gulp. Broccolli arbetar initialt med begreppen träd istället för filer och utför endast omvandlingar av träd till andra träd (även om de är degenererade och från en vertex).

Ett mycket rimligt teoretiskt förhållningssätt till monteringsproblemet löser inte problemet med antalet tillägg till Broccolli. Tyvärr finns det cirka två dussin av dem och de utför bara de mest grundläggande uppgifterna. Om du vill prova något nytt, titta på Broccolli, det är tillräckligt snabbt, det utvecklas aktivt, men förmodligen är det fortfarande fuktigt för seriösa projekt.

Brunch

Brunch skapades med samma mål – att slå Grunt på alla fronter, men närmade sig det från en helt annan vinkel. Brunch-utvecklarna bestämde sig för att ta en god förståelse för ämnesområdet, det vill säga att göra ett mindre mångsidigt verktyg som kommer att vässas specifikt för front-end-uppgifter, till exempel utan några inställningar, förstå att *.js är en fil med scripts, *.coffee är CoffeeScript och så vidare. Brunch är ganska snabb, mycket snabbare än Grunt, men något långsammare än Gulp. De otvivelaktiga fördelarna med Brunch inkluderar en riktigt kompakt konfiguration, som är flera gånger mindre än den för Grunt och Gulp. Här är till exempel en enkel brunchkonfiguration:

Exports.config = filer: javascripts: joinTo: "javascripts/app.js": /^app/ "javascripts/vendor.js": /^(bower_components|vendor)/ stylesheets: joinTo: "stylesheets/app.css" ordning :after: ["vendor/styles/helpers.css"] mallar: joinTo: "javascripts/app.js"

Observera att konfigurationen kan skrivas både i CoffeeScript (som i det här fallet) och i vanlig JS. Vi skapar en vanlig modul som returnerar JSON med bygginställningar.

Lägg märke till joinTo- och beställningsnycklarna. Det här är domänkunskapen jag pratade om - på konfigurationsnivå vet Brunch att du med största sannolikhet kommer att vilja slå ihop filer, några före andra. Detta är vad som låter dig ersätta 400 rader av Grunt-konfigurationen med 20-30 rader brunch.

Dessutom är brunchens ekosystem mycket mindre än Grunt och till och med Gulp. Det finns cirka 50 plugins (jämfört med 450+ för Gulp, till exempel), utvecklingen går inte särskilt snabbt, i allmänhet är allt ganska trist här.

Sammanfattningsvis: om du verkligen gillar korta konfigurationer är hastigheten viktig, men du behöver inga speciella åtgärder på byggstadiet, då kan du titta på Brunch. Förvirrad, naturligtvis, ett litet antal plug-ins, men kanske situationen kommer att förändras.

ENB

Och till sist, den sötaste delen. Jag vill prata om byggsystemet som utvecklats på Yandex av Marat Dulin, som kallas ENB. Detta är vad vi för närvarande använder i vårt projekt. Dess tillvägagångssätt skiljer sig fundamentalt från alla beskrivna system: det skapades ursprungligen för att arbeta med projekt med BEM-metoden, även om, som författaren noterar, dess plattform är fri från BEM-ideologin och kan användas för alla projekt med lämplig struktur .

Kortfattat, vad är poängen. I ENB arbetar vi med konceptet med ett mål, det vill säga den slutliga filen som behöver samlas in, eller en nod (mapp, i det allmänna fallet, en sida), för vilken en viss uppsättning filer behöver samlas in . För att bygga målfilen använder vi ett antal tekniker (i grova drag plugins i Grunt-termer, även om teknikerna är mindre och mer specialiserade). Först och främst bestämmer ENB den initiala uppsättningen filer som behövs för att bygga målen (detta görs av flera grundläggande teknologier som arbetar med BEM-metoden som standard, det vill säga de letar efter en *.bemdecl-fil som innehåller beroenden av denna nod på olika block), distribuerar det helt och hållet är det ett beroendeträd (när blocket som din sida beror på beror på ett annat, ingår båda i rätt ordning) och hittar sedan de filer som behövs för varje registrerad teknologi. Sedan följer ENB sekvensen av filtransformationer som beskrivs i konfigurationen (här kan du spåra lite analogi med Gulp). Trots vissa skillnader från standardbyggsystemsmetoden är det ganska enkelt att arbeta med ENB när du väl förstår de grundläggande koncepten.

De främsta fördelarna med ENB: monteringshastighet, på grund av ett flexibelt cachingsystem och möjligheten att utbyta mellanliggande data mellan olika tekniker, parallellisering av oberoende processer och uppdelning av de tyngsta teknologierna i separata delprocesser. Det är ovanligt enkelt att skriva ny teknik till ENB om du inte är nöjd med beteendet hos standard.

Nackdelarna inkluderar det faktum att ENB-konfigurationen är ganska utförlig, eftersom det är möjligt att kontrollera absolut alla steg i monteringen. Dessutom skrevs ENB fortfarande för BEM-metoden, och att koppla den till ett projekt med en helt annan struktur kommer att kräva extra gester. Det finns inte många skrivna teknologier för ENB (cirka 60), men den klarar de flesta uppgifterna i BEM-projekt med råge.

För att sammanfatta: ENB är det bästa valet för projekt baserade på BEM-metoden, som jag personligen tycker är mest lämplig för medelstora till stora webbplatser, eftersom organisationen av koden i blockregler och pip. Det är väldigt snabbt, samlar dussintals sidor och hundratals filer på några sekunder, är lätt att sätta upp och trevlig att använda. Om ditt projekt är stort, du blir förvirrad i koden och redigerar tusentals rader med filer, jag råder dig att studera BEM mer i detalj som ett sätt att organisera strukturen i front-end-projekt. Och när du älskar BEM kommer du att älska ENB som det mest inbyggda byggverktyget för BEM-projekt.

I den här artikeln kommer vi att i detalj analysera processen för att bygga ett front-end-projekt, vilket har slagit rot i mitt dagliga arbete och avsevärt underlättat rutinen.
Artikeln gör inte anspråk på att vara den ultimata sanningen, eftersom det idag finns ett stort antal olika montörer och sätt att montera, och alla väljer att smaka. Jag kommer bara att dela mina tankar om detta ämne och visa mitt arbetsflöde.

Vi kommer att använda Gulp-byggaren. Följaktligen måste du ha Node js installerat i ditt system. Vi kommer inte att överväga att installera en nod för en specifik plattform, eftersom den googlar på ett par minuter.
Och till att börja med kommer jag att svara på frågan - varför Gulp?
Av de mer eller mindre drägliga alternativen har vi Grunt och Brunch.
När jag först började gå med i montörerna fanns både Grunt och Gulp redan på marknaden. Den första dök upp tidigare och har därför en större community och en mängd plugins. Enligt npm:
Grunt - 11171 förpackningar
Gulp - 4371 paket

Men Grunt verkade för ordrik för mig. Och efter att ha läst flera jämförelseartiklar - jag föredrog Gulp för dess enkelhet och synlighet.
Brunch är ett relativt ungt projekt, med alla plus och minus som följer av detta. Jag tittar på den med intresse, men jag har inte använt den än.

Låt oss börja:

Låt oss skapa en mapp för vårt projekt, till exempel "habr". Öppna den i konsolen och kör kommandot

npm init

Du kan bara trycka på Enter på alla installationsfrågor, eftersom. nu är det inte viktigt.
Som ett resultat kommer vi i mappen med projektet att generera en package.json-fil, ungefär så här

( "name": "habr", "version": "1.0.0", "description": "", "main": "index.js", "scripts": ( "test": "echo "Fel: inget test specificerat" && exit 1" ), "author": "", "license": "ISC" )

Låt oss ändra det lite för att passa våra behov:

( "name": "habr", "version": "1.0.0", "description": "", "author": "", "license": "ISC", "devDependencies": ( "gulp": "^3.8.1") )

i devDependencies-blocket indikerade vi att vi behöver gulp och kommer omedelbart att registrera alla våra plugins.

Plugins:

Med stilar gör jag samma sak som med js, men istället för rigger "a, använder jag importen inbyggd i SCSS.
Vår main.scss kommer att se ut så här:

/* * Tredje part */ @import "CSS:../../bower_components/normalize.css/normalize.css"; /* * Anpassad */ @import "partials/app";

På så sätt är det enkelt att styra i vilken ordning stilar ingår.
Låt oss kontrollera vår uppgift genom att köra

gulpstyle:bygga

Samlar bilder

Bildkartan kommer att se ut så här:

Gulp.task("image:build", function () ( gulp.src(path.src.img) //Välj våra bilder. pipe(imagemin(( //Komprimera dem progressivt: true, svgoPlugins: [(removeViewBox: false) )], använd: , interlaced: true ))) .pipe(gulp.dest(path.build.img)) //Och släng in build .pipe(connect.reload()); ));

Jag använder standardinställningarna för imagemin, förutom interlaced. Du kan läsa mer om API:et för detta plugin.
Om vi ​​nu lägger en bild i src/img och kör kommandot

gulp image:build

då kommer vi att se vår optimerade bild i konstruktion. Gulp kommer också vänligen att skriva i konsolen hur mycket utrymme den sparat för användare av vår sida :)

Teckensnitt

Med typsnitt behöver jag oftast inte göra några manipulationer, men för att inte bryta paradigmet "Vi jobbar i src/ och bygger in build/" - kopierar jag bara filer från src/fonts och klistrar in dem i build/fonts . Här är uppgiften

Gulp.task("fonts:build", function() ( gulp.src(path.src.fonts) .pipe(gulp.dest(path.build.fonts))));

Låt oss nu definiera en uppgift som heter "bygga", som kommer att köra allt som vi har kodat här

Gulp.task("build", [ "html:build", "js:build", "style:build", "fonts:build", "image:build" ]);

Filändringar

För att inte klättra hela tiden i konsolen, låt oss be gulp köra den nödvändiga uppgiften varje gång en fil ändras. För att göra detta, skriv följande uppgift:

Gulp.task("watch", function()( watch(, function(event, cb) ( gulp.start("html:build"); )); watch(, function(event, cb) ( gulp.start( "style:build"); )); watch(, function(event, cb) ( gulp.start("js:build"); )); watch(, function(event, cb) ( gulp.start("image :build"); )); watch(, function(event, cb) ( gulp.start("fonts:build"); )); ));

Att förstå borde inte vara ett problem. Vi följer helt enkelt våra sökvägar definierade i sökvägsvariabeln, och i funktionen som kallas när filen ändras ber vi dig köra den uppgift vi behöver.
Försök att köra i konsolen

gulp klocka

och ändra olika filer.
Tja, är det inte coolt?)

webbserver

För att njuta av miraklet med livereload måste vi skapa en lokal webbserver åt oss själva. För att göra detta, skriv följande uppgift:

Gulp.task("webserver", function() ( connect.server(( host: server.host, port: server.port, livereload: true )); ));

Det finns inte ens något att kommentera. Vi kommer helt enkelt att starta servern med livereload på den värd och port vi har definierat i serverobjektet.

rengöring

Om du lägger till någon bild, kör sedan uppgiften image:build och radera sedan bilden - den kommer att finnas kvar i build-mappen. Så det skulle vara bekvämt att regelbundet städa upp det. Låt oss skapa en enkel uppgift för detta

Gulp.task("clean", function (cb) ( rimraf(path.clean, cb); ));

Nu när du kör kommandot

suga rent

det kommer bara att ta bort build-mappen.

Och till sist, lite nåd

Den här uppgiften har ingen kritisk funktion, men jag gillar den verkligen :)

Gulp.task("openbrowser", function() ( opn("http://" + server.host + ":" + server.port + "/build"); ));

När vi behöver det kommer vi att starta det – och en flik med vårt projekt öppnas automatiskt i vår webbläsare.
Det är lugnt :)

slutackord

Det sista - vi kommer att definiera en standarduppgift som kommer att köra hela vår montering.

Gulp.task("standard", ["bygga", "webbserver", "bevaka", "öppna webbläsare"]);

Din sista gulpfile.js kommer att se ut ungefär så här.
Låt oss nu köra i konsolen

Och voila :) Tomten för ditt projekt är redo och väntar på dig.

Ett par ord avslutningsvis

Den här artikeln var tänkt som ett sätt att fräscha upp det svåra med att bygga frontend-projekt igen, och att enkelt överföra denna upplevelse till nya utvecklare. Du behöver inte använda det här byggalternativet i dina projekt. Det finns yeoman.io , där du hittar generatorer för nästan alla behov.
Jag skrev den här kranen av 2 anledningar.
– Jag gillar att använda rigger i min html-kod
- I nästan alla builds som jag har sett, används en temporär mapp (vanligtvis .tmp/) för att registrera mellanliggande build-resultat. Jag gillar inte det här tillvägagångssättet och jag ville bli av med tillfälliga mappar.
- Och jag ville ha allt detta ur lådan :)

min fungerande version du kan ladda ner assemblern på min github.

Jag hoppas att artikeln var användbar för dig :)

P.S. om alla fel, brister och jambs - skriv gärna i en personlig

24 september , 2016

Följande ämnen kommer att behandlas: arbeta med sass-stilar med hjälp av källkartor, limning och komprimering av js-filer, bygga requirejs med rjs, förbearbetning av html, rensning och kopiering av filer, optimering av bilder, höja en lokal webbserver och visningsläge - watch-tasks. Välkommen till artikeln, det kommer att finnas mycket intressant!
P.S. Det finns mycket material, så artikeln kommer att delas upp i 3 delar: monteringsgrunder och projektorganisation, att skriva en testansökan på Backbone + Require.js och att faktiskt bygga med gulp.

Varför du behöver bygga en frontend.

En av de viktigaste principerna i utvecklingen är modularitet. Dela upp projektkoden i många små, idealiskt löst kopplade bitar-moduler. Detta gäller mycket mer än bara JavaScript-kod. Detta gäller stilar, och html-mallar, till olika bibliotek.

Strukturen för en enkel applikation skriven i Backbone + Require kan se ut ungefär så här.

Och det här är ett litet testprojekt, i en riktig applikation kan det finnas hundratals och tusentals filer. Att tvinga användarens webbläsare att göra hundratals http-förfrågningar är åtminstone omänskligt. Vi måste säkerställa den snabbaste laddningen av tjänsten vi har skrivit. Därför är en av de viktigaste uppgifterna för byggverktyg minifiering, minska antalet filer som används i projektet, limma dem i buntar. Vid utgången bör vi ha en mer koncis struktur, till exempel så här:

Skillnaden är tydligt synlig: istället för dussintals filer har vi en index.html, en css-fil, optimerade och komprimerade bilder i en separat mapp, även om detta inte syns på skärmdumpen :-)

Och också det mest intressanta: i mappen js fick vi bara 3 komprimerade filer.
P.S. Varför tre och inte en ska jag berätta senare.
Observera att detta är själva strukturen för testapplikationen som vi kommer att skriva inom kort.

Jag har bara beskrivit en anledning till att använda byggverktyg, men det räcker för att du ska börja använda gulp, grunt, webpack eller liknande i dina projekt. Och det spelar ingen roll om vi skriver en enorm tjänst, ett litet SPA (som i vår artikel) eller en målsida. Monteringsprinciperna är desamma för alla projekt och skiljer sig endast i mångfalden av uppgifter och tillvägagångssätt för deras lösning. I vårt exempel kommer vi att skapa en struktur som kan utökas på vilket sätt som helst i framtiden, men resultatet kommer alltid att vara en prydlig hög med filer, redo att hällas in i din produktions - stridsplats.

Hur man organiserar ett projekt på rätt sätt.

Principen är denna: det finns en sektion med utvecklarfiler, det finns med insamlade filer och allt annat som den här grejen tjänar. Låt oss skapa 2 mappar i roten av projektet: src och build. I src och bara i src kommer vi att arbeta, skapa nya filer, redigera dem och allmänt ha kul. I skärmdumpen ovan, där det finns ett par dussin filer, såg du exakt innehållet i src-mappen i vårt testprojekt. Och precis nedan finns några snygga filer från build-mappen. Den bildas endast automatiskt, av monteringsverktyg, inget behöver redigeras där. Hur som helst, med varje sammansättning skrivs dess innehåll över med nya filer (och i utvecklingsläget finns det ingen build-mapp alls - den raderas för att inte vara ett öga)

Förutom src och build kommer filerna package.json, gulpfile.js, mappen node_modules och, valfritt, .gitignore (om du arbetar med git) att finnas i roten. Du kan fortfarande se loggmappen i mitt ställe - det här är en produkt av apache och en långvarig vana att hålla projektloggar i sin egen mapp, naturligtvis, utesluta den från git-förvaret :-)

Så här ser hela projektstrukturen ut:

Enligt innehållet i bygget tror jag att det inte finns några frågor, jag kommer att förklara mer detaljerat om src:

  • 1. html - index.html, projektets rotindexfil. Varför inte direkt vid rotkällan? Eftersom det kommer att förbearbetas och skapas av gulp. Hur får vi reda på lite senare, när vi ska ta tag i monteringen.
  • 2. img - bilder, ej komprimerade, normala
  • 3. js - alla javascript-rörelser av projektet, ryggradsmodeller och vyer
  • 4. lib - tredjepartsbibliotek som backbone.js, require.js, lodash.js och andra
  • 5. skript - js-skript som behövs på en produktionsplats, men som inte behövs i utvecklingsläge. Detta avser koder för analyser, olika experiment och andra marknadsföringsdelar.
  • 6. stilar - sass filer med stilar. Den sammansatta css-filen kommer att läggas till i samma mapp (endast för utvecklingsläge)
  • 7. tpl - html-mallar. Används av Backbone-vyer som använder textpluginen require.js

Utseendet på testapplikationen är ganska fult. Man kan säga att den här typen av skit görs med ett par rader html och css-kod utan en enda js-fil.
Men vårt mål är inte att rita en vacker bild, utan att skapa en pålitlig projektstruktur och överväga så många aspekter av monteringen som möjligt. När projektet växer till hundratals filer kommer vi att vara redo för denna plåga och lätt klara av de ökade volymerna. Därför kommer vi, trots testapplikationens litenhet och yttre elände, att lära oss principerna för montering för stora och komplexa projekt.

Vilka monteringsuppgifter ska vi lösa.

Låt mig påminna er om att vi kom överens om två byggsätt: utveckling och produktion. Vi kommer att skriva alla våra uppgifter med dessa två lägen i åtanke. Alla operationer behövs inte i utvecklingsprocessen, och inte alla i monteringen för produktion.

Här är en lista över vad vi kommer att göra efter att ha skrivit en testansökan:

  • 1. Rensa filer och mappar från resultatet av föregående build
  • 2. Bygga css från sass-filer, med och utan komprimering
  • 3. Koppla källkartor till stilar, samtidigt visar jag med ett exempel varför detta behövs
  • 4. Bygga ett js-paket med requirejs
  • 5. Limma och komprimera enskilda js-filer (analys)
  • 6. HTML-förbearbetning
  • 7. Bildoptimering och komprimering
  • 8. Höj en lokal webbserver
  • 9. Uppgifter för att övervaka filer när du arbetar i utvecklingsläge - watch-tasks
  • 10. Samla separata uppgifter till en hög - slutuppgifter för produktion-montering och utvecklingsarbete

Så vi diskuterade varför vi behöver bygga frontend överhuvudtaget, bestämde oss för strukturen för projektet, analyserade i detalj vad vi vill ha från bygget och pratade i allmänna termer om testapplikationen. I nästa del av artikeln kommer vi att skriva en enkel Backbone-applikation i samband med Require.js. Om du inte är bekant med Backbone och/eller Require.js, så finns det inget att oroa sig för. Det finns faktiskt inte tillräckligt med ryggradskod i applikationen. Du kan enkelt använda ditt favoritbibliotek istället, eller bara skriva javascript/jquery-kod och hoppa över requirejs-inställningssektionen.

Gentleman's set av frontend-utvecklare

Det är ingen hemlighet att en modern front-end-utvecklare måste ha ett av projektbyggarverktygen i sin arsenal, som t.ex. klunk eller Grymta. Tills en tid hade Grunt monopol i denna fråga, men en grupp utvecklare som separerade från Grunt bestämde sig för att skapa sin egen lätta och snabba Gulp-uppdragshanterare.

I den här artikeln kommer vi att förbereda ett startpaket från grunden för användning i framtida projekt.

Vilka tekniker använder vi

  • Programvaruplattform: Node.js
  • CSS-förprocessor: nål
  • Aktivitetshanteraren: klunk

Varför behöver en frontender en uppgiftshanterare?

Tills nyligen undrade jag själv varför jag behöver lägga tid på att sätta upp aktivitetshanterarens konfiguration, om jag redan är bra på layoutlayouter, tills jag började använda CSS-förprocessorer.

CSS-förprocessorer är riktigt bekväma och snabbar upp skrivstilar, men att kompilera kod skriven i en förprocessor till vanlig CSS är inte en trivial uppgift som kan lösas med en knapp. Det är här uppgiftsledaren kommer till vår hjälp. Konverteringen av koden sker inte genom att trycka på en knapp, allt sker online utan ditt deltagande (naturligtvis om allt är korrekt inställt).

Naturligtvis går uppgifterna för en uppgiftshanterare långt utöver de processer som är kopplade till att konvertera förprocessorkod till ren CSS. Projektmontören sysslar även med minifiering, sammanlänkning, kontroll av koden för fel, sammansättning av bilder till sprites, optimering av bilder för webben, etc. Du skapar helt enkelt en massa logiskt separerade filer i ditt projekt, som sedan bekvämt samlas i en katalog, redan bearbetade och redo att fungera i webbläsaren. Men mer om det senare, men nu börjar vi med förberedelserna.

Installerar Node.js

Om du vet hur du installerar node.js på ditt system och använder det, hoppa gärna till nästa rubrik.

Jag vill omedelbart varna för att alla beskrivna åtgärder är relevanta för MacOS X, men generellt tillämplig på andra Unix system. Utveckling genom uppgiftshanteraren och kommandoraden in Windows något svårare och kommer inte att beskrivas här. Men om du fortfarande använder Windows och inte är redo att ge upp det, kan jag föreslå alternativet att använda en virtuell maskin med installerad ubuntu, Jag använder det här alternativet på mitt hemsystem, vilket i allmänhet är ganska bekvämt.

Så det första vi måste göra är att ladda ner och installera paketet node.js på vårt system för att arbeta med noden genom konsolen. Vi går till den officiella webbplatsen för node.js och laddar ner den senaste stabila versionen för ditt system. När det har installerats bör nodkommandot vara tillgängligt på din kommandorad. För att kontrollera att din nod fungerar, skriv in kommandot på kommandoraden

versionen av installerad node.js bör visas som svar. Om allt är bra går vi vidare.

Projektkatalogstruktur

I våra projekt kommer vi att använda en enhetlig version av strukturen:

Utveckla - utvecklingsrotkatalog└─start - projektkatalog├─bygga - bygg sammansatt av uppgiftshanteraren├─resurs - alla källfiler för utveckling (.psd, etc.)├─källa - utvecklingskatalog│├─css - katalog för stilutveckling││├─bilder - alla statiska bilder││├─sprites - bild samlad i en sprite││├─delvis - anpassade stilfiler│││├─mixins.style - anpassade mixins│││└─stilar - anpassade stilar││├─leverantör - andra externa stilfiler││└─stilar - huvudformatmall│├─teckensnitt - teckensnittskatalog│├─bildg - katalog över dynamiska bilder│├─js - JavaScript-utvecklingskatalog││├─_*.js - js sidofiler││├─_main.js - huvudsakliga anpassade js││└─main.js - main js-fil│├─.htaccess - konfiguration för servern│├─*.html - sidmarkeringsfiler│├─sidor.html - en fil med länkar till alla sidor i mallen│├─index.html - sidmarkeringsindexfil│└─inkludera - katalog med inkluderade uppmärkningsfiler│ └─*.html - Inkluderade uppmärkningsfiler (header.html, etc.)├─package.json - npm-pakethanterarens konfiguration├─gulpfile.js - Gulp-konfiguration├─stylus.mall.mustasch - mask för att läsa sprites├─Att göra - att göra lista└─.gitignore - git config

Installation

I konsolen, använd cd-kommandot för att gå till utvecklingsrotkatalogen, skapa vår projektkatalog mkdir start och gå till den.

Låt oss ställa in vår struktur för projektet via konsolen:

mkdir bygga resurs src src/css src/css/images src/css/sprites src/css/partial src/css/leverantör src/js src/mall src/mall/inkludera src/img src/fonts

Låt oss skapa de första filerna i projektstrukturen:

tryck på gulpfile.js stylus.template.mustache .gitignore src/.htaccess src/TODO src/css/styles.styl src/css/partial/styles.styl src/css/partial/mixins.styl src/js/main.js src/js/_main.js src/template/pages.html src/template/index.html src/template/include/header.html src/template/include/footer.html

Skapa package.json

alla popup-frågor kan klickas genom Enter, noden kommer att ställa in dem på standardvärden, eller fylla i de föreslagna fälten.

.gitignore

Vi talar om för git vilka kataloger som ska ignoreras och inte laddas upp till förvaret:

/node_modules/ /build/ /resurs/

Katalogen node_modules kommer att dyka upp senare efter installation av plugins och kommer att innehålla alla projektets nod plugins.

src/.htaccess

Ställ in ytterligare gzip-komprimering och cachning för servern:

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript # Servera gzip-komprimerade CSS-filer om de finns # och klienten accepterar gzip. RewriteCond "%(HTTP:Accept-encoding)" "gzip" RewriteCond "%(REQUEST_FILENAME)\.gz" -s RewriteRule "^(.*)\.css" "$1\.css\.gz" # Servera gzip komprimerad JS-filer om de finns # och klienten accepterar gzip. RewriteCond "%(HTTP:Accept-encoding)" "gzip" RewriteCond "%(REQUEST_FILENAME)\.gz" -s RewriteRule "^(.*)\.js" "$1\.js\.gz" # Visa korrekt innehåll typer och förhindra mod_deflate dubbel gzip. RewriteRule "\.css\.gz$" "-" RewriteRule "\.js\.gz$" "-" # Servera korrekt kodningstyp. Rubrik tillägg Content-Encoding gzip # Tvinga proxyservrar att cachelagra gzippade och # icke-gzippade css/js-filer separat. Rubrik tillägg Variera Acceptera-kodning ExpiresActive på ExpiresByType application/javascript "access plus 1 months" ExpiresByType image/jpg "access plus 1 month" ExpiresByType image/jpeg "access plus 1 month" ExpiresByType image/gif "access plus 1 month" ExpiresByType access image plus/png " month" ExpiresByType text/css "access plus 1 month"

src/css/styles.style

Inkludera anpassade stilfiler i huvudstilsfilen:

@import "partiell/stilar"

Observera att för inkludering av .styl-filer är tillägget inte specificerat, enligt semantiken för Stylus-förprocessorkoden. För att inkludera stilar i ett annat tillägg, som .css, krävs det senare.

ATT GÖRA

Den här sidan innehåller att göra-listan för utveckling. Du kan läsa mer om att arbeta med den här filen på PlainTasks plugin-sida för Sublime Text.

Detta slutför installationen av strukturen.

Installerar plugins med npm package manager

Node.js inkluderar som standard pakethanteraren npm, som har många plugins i sina repositories som vi måste arbeta med.

Installera Gulp Plugin

Först måste du installera Gulp globalt (med -g-omkopplaren) på vårt system

npm installera gulp -g

Du måste göra detta en gång, ytterligare global installation krävs inte.

Nu måste vi installera Gulp lokalt i projektkatalogen

npm installera gulp --save-dev

--save-dev-nyckeln säger att information om plugin-programmet (namn i förvaret och dess version) kommer att läggas till package.json config och kommer att komma ihåg det för detta projekt. Eftersom vi inte lagrar en tung mapp med node_modules plugins i git, kommer informationen om installerade plugins sparade i config att tillåta oss att distribuera allt i projektet med bara ett npm i-kommando nödvändiga plugins.

Det finns förkortningar för varje kommando, så vi kan skriva kommandot ovan i ett kortare format.

I framtiden kommer vi även att använda det förkortade kommandoformatet.

Stylus Plugin för Gulp

I våra projekt använder vi Stylus-förprocessorn som fungerar utmärkt och kompilerar på noden.

Installera:

npm i gulp-stylus -D

CSS-bearbetningsplugins

Autoprefixer- infogar automatiskt -ms- -o- -moz- -webkit- prefix i de nödvändiga egenskaperna:

npm i gulp-autoprefixer -D

CSS-minifiering- insticksprogrammet förminskar utdata-CSS-filen genom att ta bort extra mellanslag och flikar från den:

npm och gulp-minify-css -D

Bildbehandlingsplugins

Kombinera bilder till sprites- du behöver inte längre spendera timmar av dyrbar tid på att slå samman alla bilder till sprites och sedan beräkna deras koordinater, detta plugin kommer automatiskt att göra allt detta åt dig:

npm i gulp.spritesmith -D

Lägg till en mask för att beräkna positioner i sprites till den tidigare skapade filen stylus.template.mustache:

((#items)) $((namn)) = ((px.x)) ((px.y)) ((px.offset_x)) ((px.offset_y)) ((px.width)) (( px.height)) ((px.total_width)) ((px.total_height)) "(((escaped_image)))"; ((/objekt))

Lägg till anpassade mixins till mixins.styl:

SpriteWidth($sprite) bredd $sprite spriteHeight($sprite) höjd $sprite spritePosition($sprite) bakgrundsposition $sprite $sprite spriteImage($sprite) bakgrundsbildsadress($sprite) sprite($sprite) om !match( "hover", selector()) && !match("active", selector()) spriteImage($sprite) spritePosition($sprite) spriteWidth($sprite) spriteHeight($sprite)

Anslut mixinerna och den genererade filen med koordinater till huvudstilsfilen src/css/styles.styl:

@import "partial/sprite" @import "partial/mixins"

Observera att sprite-filerna måste inkluderas före de anpassade stilarna @import "partial/styles"

Bildoptimering för webben- plugin kommer automatiskt att skära bort all onödig information från dina bilder och krympa dem till optimal storlek, vilket i vissa fall kommer att minska storleken på bilder upp till 90%:

npm i gulp-imagemin -D

JavaScript-bearbetningsplugins

JS minifiering- plugin-programmet förminskar din JS-kod så mycket som möjligt, vilket minskar dess laddningstid:

npm jag gulp-uglify -D

JS Bugg Tracking- pluginet kommer noggrant att kontrollera din JS-kod för att identifiera alla inkonsekvenser och visa dem i konsolen:

npm i jshint gulp-jshint -D

HTML-bearbetningsplugins

Anslutna filer- pluginet låter dig lagra statiska delar av webbplatsen, såsom sidhuvud , sidfot , aside , etc., i separata filer och inkludera dem i valfri del av en annan fil. Det finns inget längre behov av att ändra dussintals eller till och med hundratals html-sidor i mallen vid mindre ändringar i rubriken:

npm i gulp-rigger -D

Plugin-programmet är också kompatibelt med JS.

Inkludera anpassad JS i JS-huvudfilen src/js/main.js med konstruktionen:

//= _main.js

Inkludera header.html- och footer.html-filer i index.html

//= include/header.html//= include/footer.html

Andra plugins

LiveReload- plugin-programmet eliminerar behovet av att ladda om sidan i webbläsaren varje gång för att se ändringarna, nu sker detta automatiskt när du sparar den ändrade filen:

npm i gulp-connect -D

Förhindrar att Gulp kraschar- ibland händer det att Gulp kan krascha ur klockläget vid kritiska fel (mest på grund av JS). Denna plugin försöker hålla Gulp-processer igång när det är möjligt:

npm i gulp-rörmokare -D

Byter namn på filer- det vanligaste arbetet med filnamn. Insticksprogrammet låter dig byta namn på filer helt, ändra filtillägget, lägga till prefix och postfixar, till exempel för att överföra style.styl view-filen till style.min.css:

npm jag gulp-rename -D

Rengöringsmedel- ibland finns det ett behov av att helt rensa upp byggkatalogen, här kommer ett plugin till räddningen:

Källkarta- för att dina filer ska förbli läsbara genom webbläsarfelsökning efter minifiering, måste du lägga till en källkarta till de minifierade filerna:

npm och gulp-sourcemaps -D

Avancerade klockfunktioner- plugin-programmet gör klockan smart, nu skriver den inte över alla filer i builden när bara en fil ändras, den skriver över en specifik modifierad fil, vilket sparar tid och resurser:

npm i gulp-watch -D

Kontrollera package.json

Trots allt installerade plugins, låt oss kolla vår package.json . Det borde se ut ungefär så här:

( "name": "start", "version": "1.0.0", "description": "Startpaket för front-end-utveckling", "author": "Ivan Ivanov", "license": "MIT", "dependencies": (), "devDependencies": ( "gulp": "senast", "gulp-autoprefixer": "senast", "gulp-connect": "senast", "gulp-imagemin": "senast", "jshint": "senast", "jshint-stylish": "senast", "gulp-jshint": "senast", "gulp-minify-css": "senast", "gulp-plumber": "senast", "gulp-rename": "senaste", "gulp-rigger": "senaste", "gulp-sourcemaps": "senaste", "gulp-stylus": "senast", "gulp-uglify": "senaste", "gulp-watch": "senast", "gulp.spritesmith": "senast", "rimraf": "senast" ) )

Istället för senaste, i ditt fall, kommer specifika versioner av installerade plugins att skrivas. Därför att Eftersom vi bygger vårt startpaket som kommer att användas i många projekt, rekommenderas det också att ersätta versionsvärdena med senaste för att alltid installera uppdaterade plugin-versioner i projektet.

Katalogen node_modules bör också visas i projektmappen, där alla nod-plugin-filer är lagrade. Alla nödvändiga plugins är installerade, du kan fortsätta till Gulp-konfigurationsinställningarna.

Konfigurera gulpfile.js

gulpfile.js- det här är huvudkonfigurationsfilen för vår aktivitetshanterare, det är i den som vi kommer att lagra alla inställningar och kommandon.

Allt Gulps arbete handlar om uppgift ( engelsk en uppgift). En uppgift är en separat oberoende funktion med ett namn. Varje uppgift kan anropas separat.

Kompatibilitetsläge med modern standard

För det första, i början av filen, kommer vi att ansluta kompatibilitetsläget endast enligt moderna standarder:

"använd strikt";

Du kan lära dig mer om detta direktiv.

Initiering av plugin

Plugins initieras med följande konstruktion:

var initPlugin = require("plugin-namn");

I enlighet med denna design initierar vi alla våra plugins:

Var gulp = require("gulp"), //huvudplugin gulp stylus = require("gulp-stylus"), //preprocessor stylus prefixer = require("gulp-autoprefixer"), //arrangera autoprefix cssmin = require(" gulp-minify-css"), //css minification uglify = require("gulp-uglify"), //js minification jshint = require("gulp-jshint"), //js error tracking rigger = require("gulp - rigger"), //arbetar med html och js inkluderar imagemin = require("gulp-imagemin"), //minimera bilder spritesmith = require("gulp.spritesmith"), //kombinera bilder till sprites rimraf = require( "rimraf") "), //purge sourcemaps = require("gulp-sourcemaps"), //sourcemaps rename = require("gulp-rename"), //rename files plumber = require("gulp-plumber"), // fuse to stop gulp watch = require("gulp-watch"), //extending watch connect = require("gulp-connect"); //liveload

Bankonstanter

För enkelhetens skull definierar vi omedelbart alla vägar och masker:

Var path = ( build: ( //Här kommer vi att specificera var filerna ska läggas redo efter build-html: "build/", js: "build/js/", css: "build/css/", img: " build/css/ images/", fonts: "build/fonts/", htaccess: "build/", contentImg: "build/img/", sprites: "src/css/images/", spritesCss: "src/css /partial/" ), src: ( //Sökvägar för att hämta html-källor från: "src/template/*.html", //Src/template/*.html-syntaxen säger till gulp att vi vill få alla filer med . html-tillägg js: "src/ js/[^_]*.js",//I stilar och skript behöver vi bara huvudfiler jshint: "src/js/*.js", css: "src/css/styles .styl", cssVendor: "src /css/vendor/*.*", //Om vi ​​vill lagra biblioteksfiler separat, avkommentera img-raden: "src/css/images/**/*.*", //Syntax img/**/*.* betyder - ta alla filer med alla filtillägg från mappen och underkatalogernas teckensnitt: "src/fonts/**/*.*", contentImg: "src/img/**/* .*", sprites: "src/css/ sprites/*.png", htaccess: "src/.htaccess" ), titta på: ( //Här anger vi, efter att ha ändrat vilka filer vi vill titta på html: "src/template/**/*.html", js: "src/js/**/*.js", css: "src/css/**/*.*" , img: "src/css/images/**/*.*", contentImg: "src/img/**/*.*", fonts: "src/fonts/**/*.*", htaccess: " src/.htaccess", sprites: "src/css/sprites/*.png" ), clean: "./build", //kataloger som kan rengöras outputDir: "./build" //initial rotkatalog till starta miniservern );

Observera att vi kan använda namnmasker:

  • *.js- alla filer med tillägget js
  • [^_]*.js- alla filer med tillägget js, exklusive de som börjar med ett understreck
  • *.* - alla filer med valfritt tillägg inom den aktuella katalogen
  • /**/*.html- Alla filer med .html-tillägget i den aktuella katalogen och alla underordnade kataloger

uppgift (uppgifter)

Nu när alla konstanter är skrivna kan du börja skriva uppgifter. Alla uppgifter har följande struktur:

Gulp.task("uppgiftsnamn", function()( //vissa funktioner ));

Miniserver och LiveReload

Först och främst kommer vi att ställa in den lokala servern och LiveReload:

// Lokal server för utveckling gulp.task("connect", function()( connect.server(( //set up server configs root: , //serverstart rotkatalog port: 9999, //vilken port vi kommer att använda livereload : true //initiera LiveReload operation )); ));

Troligtvis kommer du ofta att behöva arbeta samtidigt med flera projekt samtidigt. Servern låter dig köra många servrar samtidigt, det räcker med att registrera din port för olika projekt.

Bygg HTML

// uppgift för html-byggnad gulp.task("html:bygga", funktion () ( gulp.src(path.src.html) //Välj filer från den nödvändiga path.pipe(rigger()) //Kör genom rigger . pipe(gulp.dest(path.build.html)) //ladda upp dem till build-mappen .pipe(connect.reload()) //och starta om vår server för uppdateringar));

JS bygger

// kontrollerar js för fel och matar ut dem till konsolen gulp.task("jshint:build", function() (retur gulp.src(path.src.jshint) //select filer från den nödvändiga path.pipe(jshint( )) //kör genom jshint .pipe(jshint.reporter("jshint-stylish")); //stil utmatning av fel till konsolen )); // javascript byggnad gulp.task("js:build", function () ( gulp.src(path.src.js) //Hitta vår huvudfil.pipe(rigger()) //Kör igenom rigger .pipe(sourcemaps) .init()) //Initialisera källkarta .pipe(uglify()) //Komprimera vår js .pipe(sourcemaps.write()) //Skriv maps.pipe(rename((suffix: ".min"))) / /lägg till suffixet.min till utdatafilen file.pipe(gulp.dest(path.build.js)) //ladda upp den färdiga filen för att bygga .pipe(connect.reload()) //Och starta om servern ));

Sprite bygg

Alla bilder som ska sprites läggs till i katalogen src/css/sprites/ och blir, efter att ha körts genom Gulp, en enda sprite-bild. Sprites bör inte innehålla logotyper och bakgrunder utan tydliga mått.

// build sprites gulp.task("sprites:build", function () ( var spriteData = gulp.src(path.src.sprites) //välj var du vill få bilder att slå samman till en sprite.pipe(spritesmith(( imgName) : " sprite.png", //namn på spritebilden cssName: "sprite.styl", //stilnamn där vi lagrar bildpositioner i sprite imgPath: "images/sprite.png", //sökväg där sprite ligger cssFormat: "stylus", //format i vilket vi bearbetar positioner cssTemplate: "stylus.template.mustache", //maskfil cssVarMap: function(sprite) ( sprite.name = "s-" + sprite.name // namnet på varje sprite kommer att bestå av ett filnamn och konstruktionerna "s-" i början av namnet ) ))); spriteData.img.pipe(gulp.dest(path.build.sprites)); // sökväg där vi sparar bilden spriteData.css.pipe(gulp.dest(sökväg .build.spritesCss)); // sökväg där vi sparar stilar ));

För att visa en sprite, använd bara en mixin. Till exempel, för filen lorem.png, kommer urvalet från spriten att se ut så här:

Lorem sprite($s-lorem)

Nu kommer .lorem-objektet att ta bildens mått och själva bilden som bakgrund.

Bygg av statiska bilder

Statiska bilder är bilder som används i layoutmallen.

// bygg statiska bilder gulp.task("image:build", function () ( gulp.src(path.src.img) //Välj våra bilder. pipe(imagemin(( //Komprimera dem progressivt: true, // compression.jpg svgoPlugins: [(removeViewBox: false)], //compression.svg interlaced: true, //compression.gif optimizationLevel: 3 //komprimeringsnivå från 0 till 7 ))) .pipe(gulp.dest(sökväg. build.img)) //ladda upp för att bygga .pipe(connect.reload()) //starta om servern ));

Skapa dynamiska bilder

Dynamiska bilder är innehållsbilder som kommer att ändras på webbplatsen och som ingår på mallnivå endast i demonstrationssyfte. Det kan till exempel vara bilder för nyheter osv.

// bygg dynamiska bilder gulp.task("imagescontent:build", function() ( gulp.src(path.src.contentImg) .pipe(imagemin(( //Komprimera dem progressivt: true, //compress.jpg svgoPlugins: [(removeViewBox: false)], //compression.svg interlaced: true, //compression.gif optimeringsnivå: 3 //komprimeringsförhållande från 0 till 7 ))) .pipe(gulp.dest(path.build.contentImg)) //avlasta för att bygga .pipe(connect.reload()) //starta om servern ));

Bygg CSS

// bygg anpassad css gulp.task("cssOwn:build", funktion () ( gulp.src(path.src.css) //Välj vår huvudstilmall. pipe(sourcemaps.init()) //initialize soucemap . pipe (stylus(( compress: true, "include css": true ))) //Kompilera stylus .pipe(prefixer(( webbläsare: ["senaste 3 versionen", "> 1%", "dvs. 8", "dvs. 7 "] ))) //Lägg till leverantörsprefix.pipe(cssmin()) //Compress.pipe(sourcemaps.write()) //write sourcemap .pipe(rename((suffix: ".min"))) / / lägg till suffix.min till utdatafilnamn.pipe(gulp.dest(path.build.css)) //unload för att bygga .pipe(connect.reload()) //starta om servern ));

Separat uppgift för externa stilar:

// bygga leverantören css gulp.task("cssVendor:build", funktion () ( gulp.src(path.src.cssVendor) // Hämta leverantörsmappen .pipe(sourcemaps.init()) //initiera källan .pipe( cssmin()) //Compress.pipe(sourcemaps.write()) //skriv sourcemap .pipe(gulp.dest(path.build.css)) //ladda upp för att bygga .pipe(connect.reload() ) // starta om servern));

Låt oss också lägga till en uppgift för det allmänna CSS-bygget:

// bygg hela css gulp.task("css:build", [ "cssOwn:build", // "cssVendor:build" ]);

Om du vill bearbeta externa stilar separat från hemmastilar och ladda upp dem som separata filer, måste du avkommentera raden "cssVendor:build"

Teckensnittsbygge

// build fonts gulp.task("fonts:build", function() ( gulp.src(path.src.fonts) .pipe(gulp.dest(path.build.fonts)) //dump to build ));

Build.htaccess

// build htaccess gulp.task("htaccess:build", function() ( gulp.src(path.src.htaccess) .pipe(gulp.dest(path.build.htaccess)) //ladda upp till build ));

Allmän konstruktion

Så att vi inte behöver bygga varje del separat, låt oss skriva en uppgift för den allmänna konstruktionen:

// bygg allt gulp.task("build", [ "html:build", "jshint:build", "js:build", "sprites:build", "css:build", "fonts:build", " htaccess:build", "image:build", "imagescontent:build" ]);

Rensar byggnaden

Ibland är det nödvändigt att rensa upp byggkatalogen helt. Här kommer följande uppgift att komma till vår hjälp:

// clean build folder gulp.task("clean", function (cb) ( rimraf(path.clean, cb); ));

Titta på eller spåra förändringar i realtid

En av de viktigaste och mest användbara funktionerna hos Gulp är klockfunktionen, som gör att du i realtid kan övervaka alla ändringar av de producerade filerna och, beroende på detta, utföra specifika åtgärder:

// watch gulp.task("watch", function()( //build html vid byte watch(, function(event, cb) ( gulp.start("html:build"); )); //build sprites vid byte av watch(, function(event, cb) ( gulp.start("sprites:build"); )); //bygg kontextbilder vid byte av watch(, function(event, cb) ( gulp. start(" imagescontent:build"); )); //bygg css vid byte av watch(, function(event, cb) ( gulp.start("css:build"); )); //check js i fall of change watch(, ["jshint"]); //build js i fall av change watch(, function(event, cb) ( gulp.start("js:build"); )); //bygg statiska bilder i case of change watch(, function (event, cb) ( gulp.start("image:build"); )); //build fonts in case of change watch(, function(event, cb) ( gulp.start(" fonts:build"); )) ; //bygg htaccess vid byte av watch(, function(event, cb) ( gulp.start("htaccess:build"); )); ));

Standardåtgärder

Standardåtgärderna är vilka uppgifter aktivitetshanteraren kommer att utföra när du anger gulp-kommandot i konsolen:

// standardåtgärder gulp.task("standard", ["bygga", "bevaka", "ansluta"]);

I vårt fall kommer vi som standard att bygga vårt projekt, aktivera bevakningsläge och starta servern.

Kommandon för kommandoraden

Alla galp-kommandon för kommandoraden består av två delar - själva gulp-kommandot och namnet på uppgiften separerade med ett mellanslag. Här är en lista över kommandon som är tillämpliga på vår konfiguration:

  • klunk- kärnlag, kör standarduppgiften
  • gulp build - bygg allt
  • gulp watch - start watch
  • gulp clean - ren byggkatalog
  • gulp connect - starta server
  • gulp html:build - HTML build
  • gulp jshint:build - kontrollera JS för fel
  • gulp js:build - JS build
  • gulp sprites:build - sprite build
  • gulp image:build - statisk bildbygge
  • gulp imagecontent:build - dynamisk bildbygge
  • gulp cssOwn:build - anpassad css build
  • gulp cssVendor:build - extern CSS-build
  • gulp css:build - allmänt CSS-bygge
  • gulp fonts:build - font build
  • gulp htaccess:build - build.htaccess

Vid denna tidpunkt är konfigurationen av gulpfile.js klar.

Kopiera startpaketet till projektet

Låt oss först gå igenom konsolen i mappen där vi utvecklar, till exempel, cd develop/example och kopiera allt från startpaketkatalogen till vårt projekt cp -a ~/develop/start/. ~/develop/example/

Denna metod för kopiering är mest bekväm, eftersom. kommer att kopiera allt, inklusive dolda .gitignore-filer, etc.

Slutsats

Med hjälp av den här guiden har vi förberett ett startpaket för att använda Gulp i våra projekt för Front-end-utveckling.

Detta paket är också tillgängligt på GitHub.

Post Scriptum

Den här artikeln är inte slutgiltig och kommer att uppdateras beroende på ändringar och förbättringar.