Сборка проекта gulp: Как я сделал свою сборку Gulp для быстрой, лёгкой и приятной вёрстки / Хабр

Файл package.json - это файл конфигурации, который используется во многих интерфейсных проектах. Он работает с менеджерами пакетов JavaScript, такими как NPM и Yarn, для управления зависимостями вашего проекта, выпусками, скриптами и т. Д.

Чтобы подготовить этот проект, сначала убедитесь, что у вас установлен NPM. В качестве альтернативы вы можете использовать Yarn, но в приведенных здесь примерах будет использоваться NPM. Я не буду вдаваться в процесс установки, полагая, что вы уже использовали NPM и установили его.(Если нет, прочтите это руководство.)

После установки NPM перейдите в каталог проекта и запустите сценарий инициализации из NPM.

  $ cd путь / к / вашему / проекту
$ npm init -y
  

Теперь у вас должен быть файл package.json с некоторыми базовыми значениями. При необходимости вы можете изменить эти значения в любой момент.

Шаг 2. Установка зависимостей

Установив файл package.json , мы готовы установить зависимости проекта.На данный момент это:

Вы можете установить их с помощью одной команды:

  $ npm install --save-dev @ babel / core @ babel / preset-env gulp @ 4 gulp-babel gulp-plumber
  

Эти зависимости теперь будут перечислены в вашем файле package.json .

Шаг 3. Инициализация Git

Это хороший момент для инициализации Git. Перед этим создайте файл .gitignore в корне вашего проекта и добавьте к нему node_modules . node_modules - это место, где были установлены ваши зависимости, и вы избавите себя от огромной головной боли, не отслеживая этот код.

.gitignore

  node_modules  

Затем вы можете инициализировать свой репозиторий:

  $ git init
  

Шаг 4: Написание компонентов JavaScript

Для наших примеров в этой серии мы будем следовать нескольким соглашениям:

1. Компонентно-управляемый JavaScript, что означает, что мы собираемся написать отдельный файл JavaScript для каждого составная часть. В примерах будет показан фиктивный код, но структура продемонстрирует акцент на компонентах.
2. Все исходные файлы JavaScript будут помещены в каталог src , а файлы сборки будут помещены в каталог dist .

Это просто выбор, сделанный для этих примеров. Вы можете изменить любые ценности, которые вы видите в этой серии, в соответствии с вашим проектом.

С учетом сказанного, давайте создадим два компонента - Foo и Bar . Мы продолжим работать с этими компонентами на протяжении всех пяти частей этой серии.

src / components / foo.js

  class Foo {
 log (msg) {
 console.log (msg) 
} 
}  

src / components / bar.js

  class Панель {
 print (msg) {
 document.write (msg) 
} 
}  

Обратите внимание, что это оба класса ES6, и каждый из них имеет один (но разный) метод экземпляра. Foo имеет метод log , который принимает сообщения и записывает их в консоль. Bar имеет метод print , который принимает сообщение и записывает его в DOM.

Шаг 5: Gulpfile

Затем давайте создадим Gulpfile ( gulpfile.js ). Это наша конфигурация для нашей сборки. Он снабжен комментариями, чтобы вы могли следить за происходящим.

gulpfile.js

  
 const {src, dest} = require ("gulp") 
 
 const babel = require ("gulp-babel") 
 const plumber = require ("gulp-plumber") 
 
 
 exports.default = function (done) {
 return (
 src ("./ src / components / ** / *.js ") 
 .pipe (сантехник ()) 
 .pipe (
 babel ({
 presets: [
 [
" @ babel / env ", 
 {
 modules: false 
} 
] 
] 
}) 
) 
 .pipe (dest ("./ dist")) 
) 
} 
  

Шаг 6. Добавьте сценарий командной строки

На этом этапе, если у вас глобально установлен Gulp, вы сможете запустить сборку, просто вызов gulp :

  $ gulp
  

Вам не нужно следовать gulp с именем задачи, потому что экспорт по умолчанию ( exports.по умолчанию в вашем gulpfile.js ) предполагается, когда аргумент имени задачи отсутствует.

Но мне не нравится вызывать gulp непосредственно из командной строки, потому что вы неизбежно получите несколько проектов на вашем компьютере, каждый из которых (потенциально) требует другой версии Gulp. И когда вы вызываете gulp напрямую, вы используете единую глобальную версию. Таким образом, вы можете не знать, какую версию Gulp вы используете, когда запускаете gulp в командной строке, и это проблема.

Поэтому я предпочитаю использовать контекст проекта, добавляя сценарий в package.json :

package.json

  {
 "scripts": {
 "build": "gulp" 
 } 
}  

Теперь мы можем запустить сборку следующим образом:

  $ npm run build
  

И это запустит gulp , но это будет выполняться в текущем контексте (наш проект), что означает, что он будет использовать версию gulp, которая есть в проекте (в каталоге node_modules ) и требуется.

Шаг 7: Протестируйте

После успешной сборки вы увидите файл в dist для каждого компонента. Не стесняйтесь брать эти файлы, вставлять их в файл HTML и затем работать с ними.

Например, вы можете поместить файл index.html в каталог dist и указать его на оба компонента.

dist / index.html

И тогда вы можете открыть файл и консоль JavaScript, и запустите что-то вроде этого:

  var foo = new Foo () 
 foo.log ("Hello World") 
 var bar = new Bar () 
 bar.print ("Hello World") 
  

Это первая часть! Но есть еще много всего, что связано с Gulp и Babel, поэтому, пожалуйста, продолжайте серию. Следующие статьи посвящены объединению ваших компонентов в один файл.

Или вы можете перемещаться по серии:

1. Часть 1: Настройка и простая реализация
2. Часть 2: Объединенный пакет
3. Часть 3: Динамический манифест
4. Часть 4: Очистка файлов и сокращение вывода
5. Часть 5: Хеширование активов

Наш базовый процесс сборки Gulp

: Мы обновили наш процесс.Прочтите все об этом здесь.

В Foster Made мы работаем над широким спектром проектов, начиная от небольших сайтов Statamic и заканчивая сложными сайтами ExpressionEngine и крупномасштабными приложениями Angular и Symfony. Эти проекты различаются по технологии, размеру и сложности. Но они разделяют некоторые фундаментальные потребности современных веб-проектов. И эти потребности удовлетворяются за счет написания автоматизированных сценариев. По мере усложнения проекта эти средства выполнения задач видоизменяются и расширяются. Процесс сборки сложного приложения может сильно отличаться от простой сборки cms в виде плоских файлов.Но все выигрывают от базового процесса сборки.

Эти задачи необходимы для каждого проекта:

• Компиляция Sass
• Concat и минимизация Javascript
• Отдельные файлы для разработки и производства (один для упрощения отладки, а другой для минимизации и оптимизации для повышения скорости)
• Управление версиями / очистка кеша

Мы хотели универсализировать эти основные задачи, чтобы мы могли легко использовать их в качестве отправной точки для всех проектов. ПРИМЕЧАНИЕ. Мы удалили исходное репозиторий Github в пользу нашего нового репозитория пакетов npm: https: // github.com / fostermadeco / fm-site-build

В настоящее время мы используем Gulp для создания рабочего процесса сборки. Нам это нравится, потому что мы можем выполнять небольшие составные задачи и использовать потоки узлов. Когда дело доходит до отладки, это может расстраивать. Также иногда "слишком" асинхронный. Ошибки иногда бывают загадочными, и отследить источник бывает сложно. Но ни один процесс не идеален, и мы постоянно работаем над устранением этих болевых точек.

Структура каталогов

Выбор единой структуры каталогов закладывает прочную основу.Это немного отличается от проекта к проекту, но все пути настраиваются. Вот пример типичной структуры:

 .
├── gulp # <- Здесь можно определить пользовательские задачи gulp
├── dev # <- Сгенерированные предварительные ресурсы приложения
│ ├── app.css # <- Скомпилированные, объединенные файлы sass проекта
│ ├── vendor.css # <- Скомпилированные, объединенные файлы sass, скомпилированные поставщиком
│ ├── main.js # <- Объединенные файлы js с исходными картами
├── dist # <- Сгенерированные, готовые к работе активы приложения
│ ├── main-min.css # <- Минифицированный css
│ ├── main-min.js # <- Минифицированный js
│ src # <- где редактировать файлы
│ ├── scss
│ │ ├── mixins # <- Папки для партиалов sass
│ │ └── main.scss
│ └── js # <- Редактируемые файлы js, добавление во вложенные папки
├── images # <- Ресурсы изображения относительно `/`
├── fonts # <- Ресурсы шрифтов относительно `/`
├── static # <- pdfs и т. Д.Файлы, которые должны относиться к `/`
├── vendor # <- Сторонние активы
│ ├── bower_components # <- Указать путь в .bowerrc
│ ├── css # <- css другого поставщика не входит в Bower
│ └── js # <- js других поставщиков не в Bower
└── public / site /../ templates # <- Где бы ни находились ваши шаблоны
└── index.html # <- Где ваши таблицы стилей и js включены из 
 

Приложение vs.Сайт

В большинстве веб-приложений идеально, чтобы папки dev и dist содержали все ресурсы, необходимые для запуска приложения. Изображения, шрифты и т. Д. Копируются в папки dev и dist. ExpressionEngine и Statamic имеют шаблоны вне этих папок и не настроены для компиляции или перемещения. Таким образом, мы должны использовать несколько иной подход при организации активов. Важным моментом в приведенной выше структуре каталогов является то, что изображения и CSS всегда располагаются там, где сохраняются ссылки на пути между ними.Обычно мы никуда не копируем изображения, а ссылаемся на них из основной папки изображений.

Активы поставщика

Bower - это стандарт для управления и обновления внешних ресурсов. Теоретически это так же просто, как «bower install awesome-package --save». На практике я столкнулся с парой ошибок.

Делаем файлы Bower пригодными для использования

Простой способ использовать файлы Bower - просто ссылаться на них из каталога bower_components. Однако это плохо масштабируется. Вы не хотите ссылаться на 8 разных файлов в производственной среде.Нам нужен способ извлечь эти файлы из Bower и сделать их пригодными для использования в наших проектах.

Когда пакет Bower установлен, он захватывает весь репозиторий git. Как нам получить список файлов, которые мы действительно хотим включить в наш проект? Мы можем получить список файлов из "основного" свойства каждого пакета в их файле bower.json. Однако это не дает нам полностью пригодного для использования списка. Он может включать файлы .less, если вам нужен .css, или может просто быть неточным. Да, вы можете использовать неофициальное свойство overrides в bower.json, но это еще одна конфигурация, которую нужно отслеживать, и мы пытаемся консолидировать конфигурацию, потому что хотим, чтобы этот процесс был очень простым в настройке в новом проекте. Также это не решает возможную проблему со шрифтами и изображениями.

Мне очень хотелось автоматизировать весь процесс: от установки bower до создания файлов, готовых к работе. Я пробовал кучу разных пакетов и подходов в надежде решить эту проблему, но аномалии продолжают возникать. Иногда небольшой контроль над конфигурацией помогает сгладить разочарование в будущем.Введите gulp.options.js

Насколько это возможно, gulp.options.js объединяет конфигурацию для каждого сайта. Файл сильно прокомментирован и объясняет, что делает каждый параметр. Надеюсь, при запуске нового проекта это единственная конфигурация, которую нужно изменить. Он включает в себя список файлов Bower js и css, которые будут использоваться. Он также определяет каталоги шрифтов и изображения. Все в этих списках будет включено в файлы dev и dist.

Аномалии файлов шрифтов

могут представлять другую проблему, поскольку их расположение и, следовательно, ссылка на путь css зависят от пакета.Это мешает автоматизировать использование этих файлов в сборках dev и dist. Задача Bower нормализует это, переписывая '../fonts' в './fonts' в CSS, когда он копируется из Bower в папки dev и dist.

Когда поиск невозможен

Что-то вроде Browserify могло бы решить некоторые из этих проблем. И мы имели удовольствие использовать его в некоторых проектах. Но мы работаем над множеством существующих проектов, большинство из которых было бы сложно перенести для использования чего-то вроде Browserify.Наш процесс сборки Gulp проще реализовать в проектах, которые могут содержать различные существующие активы.

Всегда развивается

Так же, как ландшафт веб-технологий постоянно меняется, наш процесс сборки развивается вместе со временем. Это живой документ, который можно улучшать и настраивать по мере появления новых требований и идей.

Создание приложений Symfony2 с помощью Gulp

Сегодня Бернхард спросил в Твиттере, где мы видим, как идет работа с активами, и я ответил, что Grunt или Gulp возьмут на себя управление.В настоящее время я использую Grunt в некоторых своих проектах (в том числе для создания этого веб-сайта) и Gulp для некоторых более мелких вещей. Однако я хотел на некоторое время переместить один из моих больших проектов Symfony2 с Grunt на Gulp, и я воспринял обсуждение в Твиттере как причину, чтобы наконец сделать это. В этой статье я хочу объяснить некоторые аспекты использования Gulp (и Bower) в проекте Symfony2.

Я использую Gulp не только для создания своих ресурсов, но и для запуска тестов, покрытия кода и стиля проверки, и я рассмотрю все эти аспекты в этой статье.

Содержание

Зависимости

Сначала мне нужно поговорить о программном обеспечении и библиотеках, которые я использую в своем проекте и которые имеют отношение к этой статье.

• Gulp для выполнения задач (вместе с кучей плагинов Gulp и других модулей Node.js)
• Bower для установки и управления активами
• Sass
• Требовать JS для динамической загрузки файлов JavaScript
• Bootstrap как интерфейсный фреймворк
• jQuery , потому что я знаком с ним, а Bootstrap все равно требует этого
• PHPUnit для запуска моих тестов и покрытия кода
• PHP_CodeSniffer , чтобы проверить стиль моего кода PHP

Обратите внимание, , что эта статья была обновлена, чтобы отразить изменения в структуре каталогов в boostrap-sass v3.2

Структура проекта

Каждый проект Symfony2 (использующий стандартную версию) имеет одинаковую базовую структуру. Однако, поскольку это бэкэнд-фреймворк, он дает мало рекомендаций по организации ресурсов. Согласно соглашению, команда Symfonys assets: install скопирует все из каталога bundles Resources / public в папку web / проекта. Я использую это соглашение, чтобы упростить работу с путем к ресурсам в моих файлах Sass, JavaScript и Gulp.Вот части структуры моего проекта, которые имеют отношение к этой статье:

  - src / Bundle /
    - AcmeDemo /
        - Ресурсы / общедоступные /
            - js /
            - дерзость /
    - AcmeFrontendBundle /
        - Ресурсы / общедоступные /
            - js /
            - дерзость /
    - AcmeUserBundle /
        - Ресурсы / общедоступные
            - js /
            - дерзость /
Интернет /
    - связки /
    - компоненты/
    - css /
    - шрифты /
    - js /
Gulpfile.js  

Если я запустил команду assets: install --symlink , Symfony создаст для меня символические ссылки из каталога web / bundles / в общедоступный каталог в соответствующем пакете.В моей структуре каталог web / bundles / выглядит так:

  - Интернет / пакеты /
    - acmedemo /
    - acmefrontend /
    - acmeuser /  

Я думаю, очевидно, что каталог web / css / будет содержать скомпилированные файлы CSS, web / fonts / файлы шрифтов и web / js / файлы JavaScript. В каталоге web / components / хранятся ресурсы, загруженные Bower, и я расскажу об этом чуть позже.

Глоток

Если вы никогда не работали с Gulp и вам нужно знать, как его установить, и узнать больше об основных концепциях, вы можете обратиться к руководству по началу работы или к статье Building with Gulp в Smashing Magazine. Короче говоря, вы можете установить Gulp с помощью NPM.

Вам необходимо установить Gulp как глобально, так и локально в вашем проекте:

  $ npm install -g gulp
$ npm install --save-dev gulp  

Теперь вы можете создать Gulpfile .js и требуется модуль gulp :

  var gulp = require ('gulp');

gulp.task ('по умолчанию', function () {});  

Таблицы стилей

Сначала я хочу поговорить об управлении и построении таблиц стилей для моего проекта.

Таблицы стилей с Sass

Sass обладает замечательными функциями, которые делают его лучше простого CSS, и одна из них - возможность определять переменные. Однако, если я скомпилирую разные файлы Sass по отдельности и объединю их позже, я не смогу ссылаться на переменные из разных исходных файлов.Поскольку мне все равно нужен один файл Sass, я использую оператор import , чтобы включить их в один мастер-файл. Я помещаю master.scss в каждый пакет и импортирую каждый файл .scss пакета. master.scss из AcmeFrontendBundle включает master.scss из всех остальных пакетов. Выглядит это так:

 

@import '../../acmeuser/sass/master';
@import '../../acmeother/sass/master';  

Управление активами с помощью Bower

Прежде чем я расскажу о том, как я использую Bootstrap, мне нужно поговорить о Bower.Первое, что я сделал с Bower, - это изменил каталог загрузки по умолчанию, создав файл .bowerrc .

  {
  "каталог": "сеть / компоненты"
}  

Затем я загрузил bootstrap-sass-official (как следует из названия, официальный порт Sass для Bootstrap), используя bower install --save bootstrap-sass-official .

Использование Bootstrap

Я использую свой BraincraftedBootstrapBundle для интеграции Bootstrap в Symfony. Однако я отключил функцию автоматической настройки для Assetic, потому что я хочу настроить ее самостоятельно, используя Bower и Gulp, и поэтому это не имеет значения, используете вы пакет или нет.Bower загружает файлы Sass в components / bootstrap-sass-official / vendor / assets / stylesheets / bootstrap / , и я просто импортирую их из своего master.scss в AcmeFrontendBundle . Помните, что команда assets: install копирует файлы в web / bundles / , и там происходит компиляция.

 

@import '../../../components/bootstrap-sass-official/assets/stylesheets/_bootstrap';

@import '../../acmeuser/sass/master';
@Импортировать '../../acmeother/sass/master ';  

Таблицы стилей здания

Наконец, я достиг точки, когда мы можем говорить о создании таблиц стилей, то есть о компиляции Sass в код CSS. Для компиляции Sass я использую gulp-sass и порт Sass на Node.js (это быстрее).

  $ npm install --save-dev gulp-sass  

Благодаря тому, как я импортирую все, что мне нужно, в мой главный файл Sass, код для задачи Gulp остается небольшим и простым.

 

var sass = (sass = require ('gulp-sass'));

глоток.task ('sass', function () {
  глоток
    .src ('./ web / bundles / acmefrontend / sass / master.scss')
    .pipe (sass ({sourceComments: 'карта'}))
    .pipe (gulp.dest ('./ web / css /'));
});  

Сначала мне нужно создать символическую ссылку на ресурсы в web / bundles / , запустив php app / console assets: install --symlink . Выполнение задачи с помощью gulp sass скомпилирует таблицы стилей из всех пакетов и Bootstrap и сохранит их в web / css / master.css . В моем проекте у меня есть шаблон макета в моем пакете внешнего интерфейса, куда я теперь могу включить эту таблицу стилей.

Теперь все, что касается таблиц стилей, должно работать; кроме Glyphicons, предоставляемых Bootstrap.

Гильфиконы

Bootstrap включает Glyphicons, иконочный шрифт, в свои таблицы стилей, ссылаясь на них с помощью bootstrap / . Однако файлы шрифтов находятся в web / components / bootstrap-sass-official / vendor / assets / fonts / bootstrap / , а код CSS - в web / css / .Я мог бы просто изменить путь, чтобы он указывал на web / components , но я разборчив, когда дело доходит до пути и того, как они выглядят (что, если кто-то проверяет источник?), И поэтому я копирую их в web / fonts / каталог с помощью задачи Gulp. Плагин gulp-copy обеспечивает именно ту функциональность, которая мне нужна. У него есть опция префикса , которая удаляет ненужные каталоги с начала исходного пути.

 

var copy = (copy = require ('gulp-copy'));

глоток.task ('шрифты', function () {
  ответный глоток
    .src ('./ web / components / bootstrap-sass-official / assets / fonts / bootstrap / *').
    .pipe (копия ('./ web / fonts', {prefix: 7}));
});  

Однако путь все равно неверный, вместо bootstrap / он должен быть ../fonts/ . К счастью, Bootstrap использует переменную для этого пути, и я могу изменить ее, добавив следующую строку перед импортом Bootstrap в мой Sass.

 

$ icon-font-path: '../fonts/';  

Запуск gulp fonts sass выполнит как fonts , так и задачу sass , и теперь все должно работать нормально.

Javascript

Я использую RequireJS в качестве модуля и загрузчика файлов для своего проекта, чтобы динамически загружать только те скрипты, которые требуются конкретной странице. Точкой входа в JavaScript является app.js в AcmeFrontendBundle . У каждого пакета есть собственный main.js , который сам требует файлов и модулей, которые ему нужны.

Загрузить JavaScript с помощью RequireJS

app.js также необходимо настроить jQuery и подключаемые модули jQuery, предоставляемые Bootstrap, поскольку для них не определены модули RequireJS.

 

require.config ({
  paths: {
    бутстрап: '../../bootstrap',
    jquery: '../../jquery',
  },
  shim: {
    'bootstrap / affix': {deps: ['jquery'], экспорт: '$ .fn.affix'},
    'bootstrap / alert': {deps: ['jquery'], export: '$ .fn.alert'},
    'bootstrap / button': {deps: ['jquery'], экспорт: '$ .fn.button'},
    'bootstrap / carousel': {deps: ['jquery'], export: '$ .fn.carousel'},
    'bootstrap / collapse': {deps: ['jquery'], экспорт: '$ .fn.collapse'},
    'bootstrap / dropdown': {deps: ['jquery'], экспорт: '$.fn.dropdown '},
    'bootstrap / modal': {deps: ['jquery'], экспорт: '$ .fn.modal'},
    'bootstrap / popover': {deps: ['jquery'], экспорт: '$ .fn.popover'},
    'bootstrap / scrollspy': {deps: ['jquery'], экспорт: '$ .fn.scrollspy'},
    'bootstrap / tab': {deps: ['jquery'], экспорт: '$ .fn.tab'},
    'bootstrap / tooltip': {deps: ['jquery'], экспорт: '$ .fn.tooltip'},
    'bootstrap / transition': {deps: ['jquery'], exports: '$ .fn.transition'},
  },
});

требуется (['основной']);  

Самая интересная часть в приведенном выше коде - последняя строка: она сообщает RequireJS о необходимости загрузки файла main.js в том же каталоге. В настоящее время в моем проекте не так много кода JavaScript, но следующий код из main.js включает предупреждающие сообщения Bootstrap.

 

define (function (require) {
  require (['jquery', 'bootstrap / alert'], function () {
    $ ('. предупреждение'). предупреждение ();
  });
});  

А как насчет кода JavaScript из других пакетов, спросите вы? Я добавил запись в опцию paths в app.js , а затем потребовал ее внизу файла.

 

require.config ({
  paths: {
    
    acmeuser: '../../acmeuser/js',
  },
  shim: {
    
  },
});

require (['основной', 'acmeuser / main']);  

Для main.js из AcmeUserBundle теперь могут потребоваться другие модули.

 

define (function (require) {
  require (['jquery'], function () {
    $ ('. предупреждение'). addClass ('привет-мир');
  });
});  

Создание JavaScript

На самом деле, в моей текущей настройке я не создаю файлы JavaScript.Поскольку я использую RequireJS, мне не нужно их объединять; Я просто копирую их в web / js / .

 

gulp.task ('js', function () {
  глоток
    .src ([
      './web/bundles/*/js/**/*.js',
      './web/components/bootstrap-sass-official/assets/javascripts/bootstrap/*.js',
      './web/components/jquery/dist/jquery.js',
      './web/components/requirejs/require.js',
    ])
    .pipe (gulp.dest ('./ web / js'));
});  

Наблюдение и перезарядка

Выполнение задач sass и js каждый раз при изменении кода Sas или JavaScript может стать утомительным занятием.Поэтому Gulp, как и большинство современных инструментов сборки, включает функцию часов. Кроме того, я использую LiveReload для автоматической перезагрузки окна браузера при изменении CSS или JavaScript.

Наблюдают

Gulp по умолчанию включает функцию watch () . Я использую шаблон глобуса для просмотра файлов Sass и JavaScript по отдельности. Конечно, можно было бы использовать только один наблюдатель для обоих, но тогда задача JavaScript будет выполняться, даже если были изменены только таблицы стилей.

 

глоток.task ('смотреть', function () {
  var onChange = function (event) {
    console.log ('File' + event.path + 'был' + event.type);
  };
  глоток
    .watch ('./ src / Acme / Bundle / * / Resources / public / sass / ** / *. scss', ['sass'])
    .on ('изменить', onChange);
  глоток
    .watch ('./ src / Acme / Bundle / * / Resources / public / js / ** / *. js', ['js'])
    .on ('изменить', onChange);
});  

Перезарядка

LiveReload - отличный инструмент для перезагрузки окна браузера при изменении файла. Сначала я устанавливаю плагин gulp-livereload, а затем включаю фрагмент в свой макет.Также можно использовать расширение для браузера, но я предпочитаю иметь все, что мне нужно, в репозитории. После установки плагина мне нужно адаптировать код задачи watch , чтобы информировать LiveReload об измененных файлах.

 

var livereload = require ('gulp-livereload');

gulp.task ('смотреть', function () {
  var onChange = function (event) {
    console.log ('File' + event.path + 'был' + event.type);
    
    livereload.changed ();
  };
  
  livereload.listen ();
  глоток
    .смотреть ('./ src / Tvst / Bundle / * / Resources / public / sass / ** / *. scss', ['sass'])
    .on ('изменить', onChange);
  глоток
    .watch ('./ src / Tvst / Bundle / * / Resources / public / js / ** / *. js', ['js'])
    .on ('изменить', onChange);
});  

В макете я проверяю, является ли среда dev , а затем включаю фрагмент LiveReload.

  // src / Acme / Bundle / FrontendBundle / Resources / views / layout.html.twig

  

Выполнение команд PHP

Я использую Gulp также для выполнения специфичных для PHP задач, а PHPUnit и PHP_CodeSniffer - лишь два из них.Поскольку Gulpfile.js - это просто файл JavaScript, запускаемый с использованием Node.js, я могу запускать произвольные команды оболочки.

PHPUnit

Я использую плагин gulp-phpunit Майка Эриксона для запуска PHPUnit с помощью Gulp.

  $ npm install --save-dev gulp-phpunit  

Я использую функцию task () , чтобы создать новую задачу с именем test . Функция src () позволяет мне использовать шаблон глобуса для выбора файлов, которые я хочу протестировать. Если вы используете другую структуру каталогов, вам необходимо адаптировать этот шаблон.

 

var phpunit = (phpunit = require ('gulp-phpunit'));

gulp.task ('тест', function () {
  return gulp.src ('./ src / Acme / Bundle / * / Tests / ** / *. php'). pipe (
    phpunit ('./ bin / phpunit', {
      отладка: ложь,
      конфигурационный файл: './app/phpunit.xml',
    })
  );
});  

Я могу выполнить задачу с помощью gulp test . Плагин gulp-phpunit предоставляет широкий спектр возможностей.Я также создаю отчет о покрытии кода.

 

gulp.task ('покрытие', function () {
  return gulp.src ('./ src / Tvst / Bundle / * / Tests / ** / *. php'). pipe (
    phpunit ('./ bin / phpunit', {
      отладка: ложь,
      конфигурационный файл: './app/phpunit.xml',
      охватHtml: './build/coverage',
    })
  );
});  

PHP_CodeSniffer

Для запуска PHP_CodeSniffer я использую плагин gulp-phpcs Дмитрия С. Симушева.

 

var phpcs = require ('gulp-phpcs');

глоток.task ('checkstyle', function () {
  ответный глоток
    .src (['src / Tvst / Bundle / ** / *. php'])
    .pipe (phpcs ({bin: './bin/phpcs', стандарт: 'PSR2', warningSeverity: 0}))
    .pipe (phpcs.reporter ('журнал'));
});  

Я также создал ярлык для выполнения покрытия и checkstyle .

 

gulp.task ('проверить', ['покрытие', 'checkstyle']);  

Команды Symfony2

В процессе сборки мне также нужно запускать команды Symfony2.Вместо плагина я использую модуль child_process , который поставляется с Node.js, для выполнения команд Shell. Поскольку Gulpfile состоит из простого кода JavaScript, нет необходимости использовать конкретный плагин.

 

var exec = require ('child_process'). exec;

gulp.task ('installAssets', function () {
  exec ('php app / console assets: install --symlink', logStdOutAndErr);
});


var logStdOutAndErr = function (err, stdout, stderr) {
  console.log (stdout + stderr);
};  

Как видите, я создал задачу Gulp для выполнения команд установки ресурсов.Я могу интегрировать эту задачу в другие задачи и, таким образом, не забуду запустить ее при создании своих активов. В моем Gulpfile у меня также есть задачи по загрузке фикстур и обновлению схемы базы данных.

Дорожная карта

Проект, для которого я использую эту систему сборки, еще не запущен в производство, поэтому кое-чего еще не хватает. Прежде всего, я не добавил минификацию CSS и JavaScript в Gulpfile. Другая проблема, с которой я столкнулся при текущей настройке, заключается в том, что каталоги components / и bundles / находятся в web / и доступны пользователям.Перед запуском в производство я хочу переместить эти два каталога в другое место.

Другая проблема, которая может стать актуальной, когда мои таблицы стилей станут больше, заключается в том, что каждое изменение в файле .scss будет вызывать компиляцию всего кода Sass (включая Bootstrap). Мне может потребоваться найти способ, например, скомпилировать пакеты по отдельности и объединить их только для производства.

В моем Gulpfile все еще отсутствуют некоторые другие мелочи. Например, я хочу использовать CSSComb для сортировки свойств в таблицах стилей, и я хочу интегрировать Autoprefixer для автоматического добавления префиксов поставщиков в свойства CSS.Также отсутствует линтинг кода Sass и JavaScript.

Заключение

Я доволен своей текущей настройкой Gulp. Как упоминалось выше, в нем отсутствуют некоторые функции, которые мне нужно добавить перед запуском в производство. Система сборки быстрая, гибкая и (надеюсь) хорошо масштабируется. Это не полностью автоматический процесс, мне нужно добавить немного конфигурации при создании нового пакета, но это случается не часто, и в этих случаях я предпочитаю контроль над автоматизацией.

Система оценена, и она хорошо работает в моей настройке и структуре моего проекта.Если вы приняли другое решение относительно структуры или вам нужны другие функции, могут возникнуть проблемы. Тем не менее я рад отзывам о моей системе. Я новичок в Gulp и не использовал его в производственном проекте, поэтому предложения приветствуются.

Обновления

Как настроить рабочий процесс с помощью Gulp v4.0.0 | автор: Jatin Varlyani

После того, как я установил Gulp, я зашел в реестр плагинов Gulp, просмотрел 3694+ плагинов и выбрал те, которые могут помочь моему рабочему процессу.Я решил использовать sass и синхронизацию браузера, что было очень полезно.

Первый шаг - создать файл package.json , набрав команду

 $ npm init 

Затем добавьте детали - пример показан ниже:

Теперь, чтобы установить необходимые зависимости, введите следующую команду.

 $ npm install -  save-dev gulp-postcss autoprefixer cssnano gulp-sourcemaps gulp browser-sync gulp-sass  

Мы определили start как «gulp» в пакете .json , так как мы хотим запустить команду gulp на npm start .

Теперь создайте файл gulp.js в корне проекта. В этом файле мы пишем команды для использования Gulp

. Поскольку мы не хотим снова и снова использовать var , мы разделяем объявления переменных запятыми.

Теперь давайте создадим путь для источника и назначения внутри одного файла.

Создаем нашу функцию style () .Эта функция будет передавать (передавать содержимое) различные преобразования из исходного кода Sass, в конечном итоге создавая кроссбраузерно-совместимый миниатюрный CSS.