Зачем нужен gulp: Зачем нужен Gulp? — Хабр Q&A — Программирование на Python и Objective-C в Mac OS

Содержание

Зачем нужен Gulp/Webpack? — Хабр Q&A

Webpack — это сборщик модулей, который позволяет писать модульный код, где каждый модуль имеет возможность импортировать различные зависимости, начиная от других модулей, до css стилей и изображений. На главной странице сайта даже есть пример, вы подаете на вход «модули с зависимостями», а на выходе получаете то, что сможет работать в браузере.

Webpack — это просто крайняя точка развития идеи самовызывающихся функций, с помощью которых пытались решить проблему загрязнения глобальной области видимости, когда каждый скрипт подключенный к странице мог свободно обращаться к любым переменным и функциям из других скриптов, что приводило к различным проблемам, вроде случайного переопределения переменных, неявных зависимостей и необходимости строгой последовательности подключения скриптов. Эта идея затем переросла в requirejs, затем в browserify и вот в наши дни — webpack/rollup/parcel. Webpack анализирует зависимости, которые вы подключаете в вашем коде и собирает из этого конечный bundle, который сможет работать в браузере.

Gulp — это менеджер задач для автоматизации различных рутинных операций, таких как минификация, тестирование, объединение файлов и тому подобное. Gulp в отличии от Webpack никак не анализирует ваш код. Он вообще ничего не делает и по-сути своей бесполезен.

Gulp — это набор оберток-плагинов над различными утилитами. Это ведет к ряду проблем — плагины перестают поддерживаться разработчиками, плагины ломаются при очередном мажорном релизе Gulp, плагины не позволяют вам использовать новую версию утилиты, до тех пор, пока разработчик плагина не выпустит новую версию плагина совместимую с новой версией утилиты. Инструмент, который изначально возник, чтобы помочь решать возникающие проблемы, сам превратился в проблему. Это всё привело к тому, что от Gulp стали отказываться в пользу чистых утилит, которые теперь запускают через npm скрипты. Если посмотрите любые популярные open-source библиотеки, например bootstrap, то сможете заметить, что в 3 версии был Gulp, в 4 версии его не стало. Использовать Gulp сегодня не имеет смысла. Идея Gulp/Grunt — умерла, так как идея оберток-плагинов не принесла ничего, кроме дополнительных проблем.

Что такое Gulp и зачем это нужно.

В этом небольшом видео хотел представить интересный инструмент для веб-разработки, который называется Gulp. Давайте будем знакомиться с этим инструментом, что это такое и зачем это нужно.

Официальный сайт Gulp:

https://gulpjs.com

Вы можете обращаться на него, если вам будет нужна официальная документация к этой системе.

Ну, и что же такое Gulp?

Gulp — это инструмент для автоматизации рутинных задач, которые возникают при веб-разработке. Это может быть не только frontend разработка, это может быть и backend разработка.

Если вы работаете с такими технологиями как html, css, javascript и.т.д. Если вы внедрите в практику своей работы такой инструмент как gulp, вы значительно ускорите скорость вашей работы и, во вторых, этот инструмент «откроет вам дорогу» к новым возможностям, которые значительно повысят ваш уровень веб-разработки и знаний.

Gulp — это просто программа, которая написана на языке программирования Javascript. Для того, чтобы начать его пользоваться, желательно знать, хотя бы основы языка Javascript. Если вы это знаете, то пользоваться программой Gulp для вас будет намного проще.

Смысл следующий: мы создаем для системы Gulp некие задания. Т.е. описываем эти задания на языке Javascript. Затем, Gulp просто выполняет эти задания в нужной последовательности, так, как мы это прописали. Т.е. Gulp — это просто система по управлению заданиями по веб-разработке. Также ее называют task manager. task — задание, manager — управлять.

Важно понимать, что Gulp — это просто некое ядро, к которому мы прикручиваем дополнительные модули, плагины, которые «учат» Gulp делать какую-то определенную функцию или работу. Устанавливая эти плагины мы получаем новые возможности в системе Gulp, которые мы можем использовать.

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

Выбираем нужный плагин, устанавливаем его в эту систему и пользуемся им.

Какие типовые задачи можно решать с помощью этой системы?

Давайте рассмотрим самые основные из них. Список этих задач может быть достаточно большой.

Задача 1. Минификация кода.

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

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

Задача 2. Объединение кода из разных файлов в один.

Вы можете объединять код из CSS, Javascript файлов и.т.д. в один. Это важно сделать также по причине скорости загрузки документа. При работе с протоколом http каждый запрос к файлу — это дополнительное время загрузки страницы.

Если вы объединяете код в один файл, загрузить его проще и быстрее, чем загрузить несколько файлов.

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

Задача 3. Работа с CSS препроцессорами: sass, less, …

Система Gulp позволяет вам использовать их в своей работе и вы получите такой мощный инструмент для того, чтобы улучшить свои навыки веб-разработки.

Задача 4. Поддержка новых стандартов языка Javascript.

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

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

Код написанный под Gulp интуитивно понятный и проект, который у вас будет получаться, достаточно компактный и удобный. В нем будет все самое необходимое, что нужно для веб-разработки.

Есть и другие решения, например, система Webpack, которая в последнее время приобретает большую популярность. Но, дело в том, что Webpack — это довольно громоздкая система и для решения каких-то простых задач устанавливать такую большую систему не очень разумно.

Gulp — это альтернатива, которая позволит вам решать эти задачи проще и быстрее.

что это и зачем использовать

Webpack — это сборщик проекта, который содержит в себе ряд полезных функций для разработки приложений.

Какие возможности предоставляет Webpack

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

Модульность

С помощью Webpack можно разбить код своего проекта (во время разработки) на кучу модулей, а потом воедино собрать в один файл в релизной версии.

Модульность позволяет разделить продукт на две версии: release (окончательная версия) и production (в производстве). В дальнейшем такой проект легче обслуживать.

Транспиляция

Транспиляция — это автоматизированный процесс переписывания кода с одного языка на аналогичный код на другом языке.

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

Встроенный сервер

Webpack имеет свой собственный сервер с режимом контроля изменений. То есть, изменяя один файл, webpack сам обновляет файлы и отображает изменения в проекте.

Обычно сервер с проектом запускается через консольную команду npm run dev и располагается по адресу http://localhost:8080.

Разделение и оптимизация

Webpack способен разделить релизный выходной файл (общий со всеми модулями) на несколько файлов поменьше. Это делается для того, чтобы избежать чрезмерной нагрузки на браузер пользователя при первой загрузки приложения. Делается это в рамках больших проектов: CRM-систем и крупных веб-приложений.

И это еще не все возможности Webpack… хотя этого вполне хватит для общего понимания инструмента. Если загорелись желание обучиться данной технологии, ниже оставлю ссылку на официальную документацию.

Webpack и Gulp: в чем различия

Webpack — это эволюционированный task-manager (или task-runner). Раньше, до появления Webpack, люди использовали Gulp и Grunt, которые также умели собирать проект (в основном верстку) и контролировали изменения в проекте в режиме реального времени.

Webpack собрал всего понемногу от своих предшественников и добавил своего, поэтому он обладает такими функциями, которых нет, например, в Gulp. Для примера, Gulp не имеет собственного dev-сервера, нет hot-reload (т.е при изменении JavaScript файла Webpack сможет отрендерить компонент в режиме реального времени), здесь нет режима unit тестирования, отсутствует babel (из коробки), да и скорость компиляции JavaScript заметно ниже.

Что должен уметь верстальщик — Блог HTML Academy

В нулевых никаких фронтов не было, и человек, который делает сайты, был просто человеком, который делает сайты. Мог и на HTML что-то собрать, и стили прописать, и на JavaScript алерты наставить, где нужно. Веб-разработка была маленькой, смешной, но самодостаточной. А потом понеслось.

Верстальщики стали больше писать на JavaScript и начали поглядывать в сторону именования «фронтендер», но всё ещё очень любили делать файлы style.css на десять тысяч строк.

И чем ближе был 2020, тем больше грань размывалась — и теперь нет разработчиков на React, которые не понимают, как сверстать макет и обвязать всё стилями. При этом спрос на чистых верстальщиков ещё остался — им не обязательно в совершенстве владеть JavaScript, а вот глубоко понимать, как быстро, точно и качественно из макета сделать страницу — обязательно.

В этом и заключается суть работы верстальщиков. Они берут у дизайнеров макет (это картинка, на которой нарисован сайт — К.О.) и собирают из него страницу. Пишут HTML, CSS, используют магию гридов, флоатов, какой-нибудь БЭМ. Стараются, в общем, делают. Молодцы.

С другой стороны, HTML сейчас даже в некоторых школах изучают — но отчего-то сразу после школы никто не спешит платить первокурсникам по 500$ за вёрстку. И тут мы приходим к тому, что в 2020 году требуют от верстальщика работодатели.

Мы в HTML Academy работаем над тем, что верстальщики после двух наших интенсивов по вёрстке находили работу, а после интенсива по JavaScript делали это вообще без проблем. И для того, чтобы чему-то обучать, мы должны понять, что требуется рынку сейчас и какие требования выставляет работодатель к верстальщику, чтобы мы могли покрывать такие требования на курсах.

Идеальная вакансия

Коля Шабалин, автор и преподаватель курсов в Академии, написал скрипт и проанализировал вакансии на hh и Хабр-карьере, выделил требования и посчитал, какие встречаются чаще. Оказалось, что усреднённая вакансия выглядела бы как-то так:

Требуется верстальщик, который:

Умеет делать адаптивную кроссбраузерную оптимизированную вёрстку, совместимую с современными браузерами. В вёрстке использует SVG.
Идеально знает CSS. Использует препроцессор Sass. Знает флексы. Умеет делать CSS-анимации и использует БЭМ. Знает библиотеку Bootstrap.
Знает HTML. В своей работе использует Сanvas. Шаблонизирует HTML с помощью PUG.
Использует Git. Умеет работать в GitHub.
Может натянуть вёрстку на CMS: Bitrix и Wordpress.
JavaScript пишет с помощью jQuery, но не чурается ES6.
Умеет автоматизировать свою работу с Node.js, npm-скрипты, Autoprefixer, Gulp или Webрасk.
Уверенно владеет Photoshop и Illustrator или знает Figma или Sketch.
Имеет своё портфолио, инициативный, готов пройти испытательный срок

Уроками информатики, как видите, даже не пахнет. Много непонятных слов, давайте разберёмся.

Верстальщический вундерлист

Умение использовать каждую вещь из этого списка немножечко повышает шансы верстальщика найти работу в 2020 году.

Кроссбраузерная вёрстка — это когда сайт во всех браузерах выглядит одинаково. Даже в IE11 (хотя это несколько сложно, учитывая одно из следующих требований).

SVG — векторный формат изображений, при котором картинки не портятся, если их растянуть.
Sass — это такая надстройка над CSS. Sass помогает избежать дублирования и структурировать код, в таком виде его легче поддерживать. Но с препроцессорами есть проблемы.
БЭМ — изобретение Яндекса, чтобы упростить вёрстку и разбить всё на блоки.
Canvas— сущность в HTML, на которой можно рисовать (люблю объяснять!).
PUG — шаблонизатор HTML, написанный на JavaScript для Node.js. Нужен, чтобы шаблонизировать. Все же любят шаблоны.
Git — система контроля версий, чтобы не делать Макет_2_Финальный_СПравками_final_наревью.html. Мы в Академии любим Git и написали про него много статей.
Натянуть вёрстку на CMS — взять WordPress или какой-нибудь там ещё движок для блога и сверстать страницу его встроенными средствами. Но по макету, чтобы дорого-богато.
Bootstrap — ещё одна библиотека, чтобы быстро верстать. Её много где используют, но киллерфичей верстальщика может стать понимание, как сверстать «как на бутстрапе», но с нуля.
jQuery — популярное ~~нечто~~ решение, которое используют, чтобы поудобнее работать с JavaScript. Порог вхождения низкий, запутанность кода — высокая. Вообще, после хороших курсов по JavaScript никакой jQuery будет не нужен, но если он используется в компании, то разобраться будет легко.
Node.js, npm-скрипты, Autoprefixer, Gulp, Webpack — инструменты, чтобы экономить кучу времени при вёрстке за счёт автоматизации.

Что там с Фотошопом и Иллюстратором

Некоторые ребята говорят, что их всерьёз кто-то использует.

Практика показывает, что все потихоньку переходят на Figma, Sketch и Avocode. Ну то есть Фотошоп и Иллюстратор, конечно, ещё много где, но по сравнению с Фигмой это как заколачивать гвозди дорогущим перегруженным графическим редактором по подписке.

Ну и потом, вспомните Adobe Flash — все постепенно пересядут на нормальную технологию, никуда не денешься.

А портфолио откуда брать?

Найти бесплатных макетов и наверстать.
Придумать самому, если есть Дизайнерская Жилка.
Пройти полноценную подготовку к работе и получить пару проектов в портфолио.

Что об этом всём думают в индустрии?

Я спросил Катю, которая раньше верстала в Яндекс.Деньгах, о том, что должен уметь верстальщик, чтобы его все хотели. Катя отвечает:

По опыту: нужно точно, быстро и адаптивно.
Точно — значит по макету: надо уметь открыть psd и померить отступы. Быстро — значит код легко изменять и его можно переиспользовать: надо знать препроцессоры и уметь правильно разделить макеты на компоненты (приходит с опытом). Адаптивно то и значит: надо знать про медиа-запросы и уметь нафлексить флексами резиновую вёрстку, или на гридах.
Чтобы собрать своё добро, нужно знать, где скачать Node.js, как скачать пакет из npm и уметь пользоваться Webpack или Gulp (если он ещё не умер): пожать, минифицировать, запустить хот-релоад. И да, Git, нужно выучить десяток базовых команд. Это необходимый минимум.
В идеале нужно освоить базовый JavaScript и React, чтобы верстать компоненты сразу на нём. И вот еще чуть-чуть, и ты уже фронтендер.
Нынче если ищут именно верстальщика, а не полноценного фронта, значит последний уже есть, а вёрстки много и/или она сложная. Значит можно не знать JavaScript, но стоит освоить любой шаблонизатор, одну из популярных методологий, познакомиться с существующими библиотеками компонентов.
Чтобы тебя все хотели, нужно много и быстро верстать. А для этого нужно активно пользоваться доступными инструментами и подходами и уметь выбирать подходящие. Что, конечно, выходит далеко за рамки знания HTML и CSS.

Катя Иванова, перевела бабушку на React.

Что ещё?

Все работодатели хотят, чтобы к ним пришёл опытный верстальщик — для этого берите и верстайте. Можно смотреть на популярные сайты, верстать по бесплатным макетам или хорошим курсам. Как определить, хорошие ли перед вами курсы, я рассказывал в статье «Как получать 100 тысяч за код». Там есть полный список вещей, которые хорошо бы знать веб-разработчику, чтобы повысить шансы на высокую зарплату.

Новая профессия не за горами

Мы перезвоним и расскажем всё о том, как стать верстальщиком.

Хочу консультацию

Нажатие на кнопку — согласие на обработку персональных данных

tars/faq.md at master · tars/tars · GitHub

Permalink

Cannot retrieve contributors at this time

English description | Описание на русском

По всем вопросам можно обращаться в gitter или по почте [email protected].

У меня webpack и NPM-scripts, я не понимаю, зачем нужен TARS с Gulp?
Для всего есть свой инструмент. Естественно, можно извернуться и для всех своих задач использовать только NPM-scripts. Но Gulp — это не только таск-менеджер (что уже делает его на одну ступень выше по удобству, чем NPM-скрипты), но и возможность легко переносить файлы в поток. С NPM-скриптами уже не так просто сделать правильную параллельную обработку задач. В любом случае потребуется еще некий index.js, в котором будет отдельно реализован последовательный flow выполнения тасков и параллельный. Также, не забываем, что и асинхронные задачи бывают.
Насчет именно webpack: инструмент был создан для того, чтобы разрешать зависимости в JavaScript изначально. Сейчас его обвесили еще плагинами, но его главная задача так и осталась прежней. Отсюда следует, что Gulp + webpack = любовь, они не конкуренты друг другу.
Можно почитать комментарии на эту тему в документации к webpack + Gulp.
Почему именно Gulp, а не Grunt?
Gulp это потоковый сборщик проектов на JavaScript. Он использует Streams и действительно является очень быстрым. Для примера у меня есть проект, где около тысячи stylus файлов, Grunt’у нужно примерно 2.5 секунды на сборку и 2 секунды на обработку autoprefixer’ом. Gulp все это делает за 0.5 секунды выигрывая у Grunt минимум в 4 раза.
Как лучше построить процесс разработки с помощью TARS?
Единого ответа тут нет. Все зависит от специфики разработки. Рассмотрим несколько типов проектов.
- Долгоиграющий и единственный. В этом случае все просто. Создавайте компоненты, страницы, храните все в какой-либо CVS — в общем, этот сценарий самый скучный.
- Много проектов с повторяющейся функциональностью. В этом случае есть несколько путей работы с TARS:
  - создать библиотеку переиспользуемых блоков и включить ее сразу в собственный форк TARS. Таким образом, при ините нового проекта в нем сразу будут все нужные блоки;
  - использовать git или любую другую CVS. Пусть заиниченный TARS находится в git, а каждый новый проект — отдельная ветка;
  - хранить библиотеку повторяющихся блоков отдельно.
- Много разных проектов. Также весьма простой сценарий, при котором каждый проект может быть отдельным репозиторием в git (или другой CVS).

Указанные способы выше — не догма, а лишь пример, как получить больше пользы от TARS.

У нас в команде есть свой сборщик на Gulp/Grunt, хотелось бы использовать наработки из него в TARS.
Можете перенести необходимые таски в user-tasks. Для использования grunt-тасков, если не хотите переписывать на Gulp, есть пакет gulp-grunt, который запускает grunt-таск в Gulp. Но все же рекомендуем портировать grunt-таск в Gulp. Тем более, все плагины для Grunt доступны в Gulp. Если необходимо, чтобы проект инитился всегда с этими дополнительными тасками, то рекомендуем создать форк TARS, добавить в нем необходимые изменения, инитить проект, с указанием ссылки на ваш форк. При этом, для упрощения обновления форка, все кастомные таски следует складывать в users-tasks, а зависимости для этих тасков указывать в user-package.json. Они будут ставиться с каждым заиниченым проектом.
У меня OS X (Ubuntu, Linux Mint …) В готовую сборку попадают не все файлы проекта.
Нужно увеличить ulimit в tars-config.js
Я ничего не понимаю в Gulp, могу ли я комфортно пользоваться данным сборщиком?
Знания работы с Gulp не обязательны. На данный момент сборщик покрывает большинство задач frontend’а. Все, что нужно знать — описано в документации.
Мне кажется, что используется слишком сложная файловая структура. Могу ли я ее модифицировать так, как нужно мне?
Если вы умеете работать с Gulp, то после переименования/удаления/создания папок, необходимо править соответсвующие таски или создавать user-tasks. Некоторые каталоги не обязательны и могут быть спокойно удалены.
Также можно спокойно расширять файловую структуру для JavaScript с использованием опции в конфиге сборщика.
Для основной папки со статикой и папки с картинками можно задать имя в опциях в конфиге сборщика.
Вроде бы все поставилось, но ничего не работает. Что делать? У меня Windows (7, 8, 10)
Скорее всего не все зависимости поставились. Запустите команду NPM i еще раз.
Если в результате выполнения данной команды есть ошибки, то большая просьба прислать их на почту ([email protected]) или в gitter.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session.
You signed out in another tab or window. Reload to refresh your session.

Зачем нужен CSS | Учебные курсы

По мере роста популярности веба в девяностых годах, также росло намерение применять к сайту определённый дизайн. Веб-разработчики полагались на конкретные теги HTML для улучшения веб-страниц:

<basefont> определял шрифт всего HTML-документа;
<font> определял гарнитуру, цвет и размер текста, который находится внутри;
<center> выравнивал по центру всё своё содержимое;
<big> увеличивал размер текста;
<strike> отображал текст перечёркнутым.

Также могли быть использованы несколько атрибутов HTML:

bgcolor определял цвет фона элемента;
text определял цвет текста;
атрибуты margin могли быть использованы для добавления пространства с любой стороны элемента.

Зачем избегать таблиц?

Но прежде всего, для создания колонок, визуального выравнивания элементов и, в целом, позиционирования элементов относительно друг друга, веб-разработчики использовали элемент <table> для дизайна своих веб-страниц, потому что он естественным образом обеспечивал визуальную сетку.

<table>
<thead>
<tr>
<th>Логотип</th>
<th colspan=»2″>Слоган</th>
</tr>
</thead>
<tfoot>
<tr>
<th colspan=»3″>Copyright 2015</th>
</tr>
</tfoot>
<tbody>
<tr>
<td>Левое меню</td>
<td>Основное содержимое</td>
<td>Правый сайдбар</td>
</tr>
</tbody>
</table>

Такой подход был громоздким по нескольким причинам:

таблицы в HTML многословны: они требуют много шаблонного кода;
разметка была семантически неверной: таблицы должны использоваться для многомерных данных;
изменение макета требовало изменения разметки: если мы хотели переместить левую колонку вправо, то должны были модифицировать структуру HTML;
таблицы были склонны к ошибкам синтаксиса: строки и ячейки для корректности должны идти и вкладываться определённым образом;
разметка была нечитаемой: таблицы вкладывались в другие таблицы, чтобы получить дополнительные колонки внутри колонок.

Именно поэтому от применения таблиц в качестве инструмента вёрстки медленно отказались и вместо них был использован CSS.

Что такое CSS

CSS (Cascading Style Sheets) означает каскадные таблицы стилей и представляет собой язык разметки стилей (как HTML или XML). Таким образом, CSS ничего не представляет сам по себе, если не связан с HTML-документом.

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

Как работает CSS

CSS выбирает элемент HTML (например, абзац), задаёт свойство для изменения (такое как цвет) и применяет определённое значение (например, красный):

p { color: red;}

Слово «стиль» может быть обманчивым. Можно подумать, CSS используется только для изменения цвета текста, размера и типа шрифта. Но CSS может задать компоновку HTML-документа, определяя высоту, ширину, внутренние и внешние поля, положение, колонки и др.

Где я могу писать CSS?

CSS как атрибут

Вы можете писать CSS непосредственно в элементах HTML с помощью атрибута style:

<p>Это важный текст.</p>

CSS в <head>

Вы можете использовать тег <style> внутри <head> вашего HTML-документа:

<!DOCTYPE html>
<html>
<head>
<title>Привет, мир</title>
<style>
p { color: red;}
</style>
</head>
<body>
<p>Этот абзац будет красным.</p>
</body>
</html>

CSS в отдельном файле

Вы можете писать свой CSS в отдельном файле с расширением .css, а затем связать его с HTML с помощью тега <link>.

CSS

p { color: red; }

HTML

<!DOCTYPE html>
<html>
 <head>
  <title>Привет, мир</title>
  <link rel="stylesheet" href="style.css">
 </head>
 <body>
  <p>Этот абзац будет красным.</p>
 </body>
</html>

Данный HTML-документ, который «вызывает» файл CSS, в нашем случае файл с именем style.css, расположен в той же папке, что и CSS-файл.

Этот третий метод, использующий отдельный CSS-файл, является предпочтительным.

Почему бы не размещать стиль прямо в HTML?

Потому что мы хотим отделить содержимое (HTML) от его представления (CSS).
Если вы хотите представить замысел этого различия, присмотритесь к замечательному CSS Zen Garden: каждый дизайн использует один и тот же HTML, но каждый раз другой CSS.

Это делает обслуживание проще: тот же CSS-файл может быть использован на всём сайте. А также обеспечивает гибкость: сосредоточьтесь на содержании с одной стороны и стилизации с другой.

Зачем нужен npm —save-dev — CodeRoad

При установке пакетов в npm, почему мы должны добавить --save-dev в конце?

Пример:

npm install gulp-angular-templatecache --save-dev

В документации онлайн ( https: / / docs.npmjs.com/cli/install) говорится: «пакет появится в вашем devDependencies .» Что это значит? Значит ли это, что если я не поставлю --save-dev , он будет установлен в другой каталог?

node.js

npm

Поделиться

Источник

user1995781

12 января 2015 в 07:16

2 ответа

Зачем нам нужен dev branch?
Я вижу, что некоторые люди используют ветвь с именем dev рядом с master для среды разработки. Даже они используют ветвь функции, они говорят, что лучше иметь ветвь dev . На самом деле я не услышал подходящего ответа, почему. Даже если есть ветвь dev, все равно нужно сделать работу, прежде чем…
Ошибка при установке npm install grunt-contrib-clean —dev-save
Вот файл package.json { name: gruntTutorial.js, version: 1.0.0, description: , main: index.js, scripts: { test: echo \Error: no test specified\ && exit 1 }, author: , license: ISC, devDependencies: { grunt: ^0.0.5.0 } } Имея этот файл package.json , при установке…

package.json имеет два места для хранения информации о зависимостях: объект «dependencies» и объект «devDependencies».

Когда вы устанавливаете приложение и запускаете «npm install», оно удаляет как зависимости, так и devDependencies. Однако, если вы сделаете «npm install —production», он снимет ONLY зависимости, NOT-devDependencies.

Идея заключается в том, что devDependencies предназначены для таких вещей, как бегуны тестов и библиотеки утверждений; вещи, которые вам нужны во время разработки, но не те, которые вам нужны, когда вы фактически развернули приложение в рабочей среде.

Поделиться

Chris Tavares

12 января 2015 в 07:31

В файле package.json он автоматически добавит модуль gulp-angular-templatecache к объекту devDependencies в файле JSON после установки его локально в вашем приложении под node_modules , как обычно.1.5.0″
},
…
}

Поделиться

Patrick Roberts

12 января 2015 в 07:21

Почему я отказался от Gulp и Grunt для скриптов npm

Я знаю, о чем вы думаете. WAT?! Разве Глоток не убил Гранта? Почему мы не можем просто остановиться на несколько минут здесь, в стране JavaScript? Я слышу тебя, но…

Я обнаружил, что Gulp и Grunt — ненужные абстракции. Скрипты npm очень мощные, и зачастую с ними проще жить.

Давайте начнем с примера…

Я был большим поклонником Gulp. Но в моем последнем проекте у меня было 100 строк в моем gulpfile и около дюжины плагинов Gulp.Я изо всех сил пытался интегрировать Webpack, Browsersync, горячую перезагрузку, Mocha и многое другое с помощью Gulp. Почему? Что ж, у некоторых плагинов было недостаточно документации для моего варианта использования. Некоторые плагины предоставляют только часть необходимого мне API. У одного была странная ошибка, при которой просматривалось только небольшое количество файлов. Еще лишены цвета при выводе в командную строку.

Это решаемые проблемы, но ни одна из этих проблем не возникла, когда я вызвал инструменты напрямую.

В последнее время я заметил, что многие проекты с открытым исходным кодом просто используют сценарии npm.Я решил отступить и пересмотреть. Мне действительно нужен был Gulp? Оказывается, нет.

Я решил попробовать использовать только сценарии npm в моем новом проекте с открытым исходным кодом. Я создал богатую среду разработки и процесс сборки приложений React, используя только сценарии npm. Любопытно, как это выглядит? Проверьте React Slingshot. Я расскажу, как создать этот процесс сборки с помощью сценариев npm, в разделе «Создание среды разработки JavaScript» на Pluralsight.

Удивительно, но теперь я предпочитаю работать со сценариями npm, а не с Gulp.Вот почему.

Что не так с Gulp и Grunt?

Со временем я заметил три основных проблемы с исполнителями задач, такими как Gulp и Grunt:

Зависимость от авторов плагинов
Устрашающая отладка
Несвязанная документация

Давайте рассмотрим каждую из этих проблем.

Проблема №1: Зависимость от авторов подключаемых модулей

Когда вы работаете с новыми или непопулярными технологиями, подключаемый модуль может вообще отсутствовать. А когда плагин существует, он может быть устаревшим.Например, недавно был выпущен Babel 6. API значительно изменился, поэтому многие плагины Gulp были несовместимы с последней версией. При использовании Gulp я застревал, потому что необходимый мне плагин Gulp еще не был обновлен.

При использовании Gulp или Grunt вы должны дождаться, пока разработчики плагина предоставят обновления, или исправить это самостоятельно. Это задерживает вашу способность использовать новые версии современных инструментов. В отличие от , когда я использую сценарии npm, я использую инструменты напрямую, без дополнительного уровня абстракции .Это означает, что когда будут выпущены новые версии Mocha, Istanbul, Babel, Webpack, Browserify и т. Д., Я сразу смогу использовать новые версии.

С точки зрения выбора ничто не сравнится с npm:

Gulp имеет ~ 2100 плагинов. У Grunt ~ 5400. npm предлагает более 227 000 пакетов, и их количество ежедневно увеличивается на 400+.

Когда вы используете сценарии npm, вы не ищите подключаемые модули Grunt или Gulp. Вы выбираете из более чем 227 000 пакетов npm.

Честно говоря, если нужный вам плагин Grunt или Gulp недоступен, вы, безусловно, можете использовать пакеты npm напрямую.Но тогда вы больше не используете Gulp или Grunt для этой конкретной задачи.

Проблема № 2: разочаровывающая отладка

При сбое интеграции отладка в Grunt и Gulp может вызывать разочарование. Поскольку вы работаете с дополнительным уровнем абстракции, существует больше потенциальных причин для любой ошибки:

Не работает ли базовый инструмент?
Плагин Grunt / Gulp сломан?
Моя конфигурация нарушена?
Использую ли я несовместимые версии?

Использование сценариев npm устраняет # 2.И я считаю, что №3 встречается гораздо реже, поскольку я обычно вызываю интерфейс командной строки напрямую. Наконец, №4 встречается реже, так как я уменьшил количество пакетов в своем проекте, используя npm напрямую, а не используя абстракцию исполнителя задач.

Проблема № 3: Несвязанная документация

Документация по основным инструментам, которые мне нужны, почти всегда лучше, чем связанные с ними плагины Grunt и Gulp. Например, если я использую gulp-eslint, я делю свое время между документами gulp-eslint и веб-сайтом ESLint.Мне нужно переключать контекст между плагином и инструментом, который он абстрагирует. Основной элемент трения в Gulp and Grunt заключается в следующем:

Недостаточно понять инструмент. Gulp и Grunt требуют от вас понимания абстракции плагина.

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

Теперь, когда я определил болевые точки, возникает вопрос: почему мы думаем, что нам нужны средства выполнения задач, такие как Gulp и Grunt?

Почему мы проигнорировали npm для сборок?

Я считаю, что существует четырех основных заблуждений , которые привели к тому, что Gulp и Grunt стали настолько популярными:

Люди думают, что сценарии npm требуют сильных навыков командной строки
Люди думают, что сценарии npm недостаточно мощны
Люди думают, что потоки Gulp необходимы для быстрых сборок
Люди думают, что сценарии npm не работают на разных платформах

Давайте рассмотрим эти заблуждения по порядку.

Заблуждение № 1

: Сценарии npm требуют сильных навыков работы с командной строкой

Вам не нужно много знать о командной строке своей операционной системы, чтобы пользоваться мощью сценариев npm. Конечно, grep, sed, awk и pipe — это навыки, которые нужно изучать на протяжении всей жизни, но вам не нужно быть мастером командной строки Unix или Windows, чтобы использовать сценарии npm . Вместо этого вы можете использовать тысячи пакетов в npm, чтобы выполнить свою работу.

Например, вы могли не знать, что в Unix это принудительно удаляет каталог: rm -rf.Это нормально. Вы можете использовать rimraf, который делает то же самое (и он работает кроссплатформенным для загрузки). Большинство пакетов npm предлагают интерфейсы, которые предполагают очень мало знаний о командной строке вашей ОС. Просто ищите в npm пакеты, которые делают то, что вам нужно, читайте документацию, учитесь на ходу. Раньше я искал плагины Gulp. Вместо этого я ищу пакеты npm. Отличный ресурс: libraries.io.

Заблуждение № 2: сценарии npm недостаточно мощны

сценарии npm сами по себе на удивление эффективны.Существуют условные перехватчики до и после:

 
{
  "name": "npm-scripts-example",
  "версия": "1.0.0",
  "description": "Пример сценария npm",
  "scripts": {
    "prebuild": "echo I run before the build script",
    "build": "cross-env NODE_ENV = production webpack",
    "postbuild": "echo Я бегу после сценария сборки"
  }
}

Все, что вы делаете, это следуете соглашениям. Приведенные выше скрипты будут запускаться по порядку в зависимости от их префикса. Сценарий предварительной сборки будет запускаться перед сценарием сборки, потому что у него такое же имя, но с префиксом «pre».Сценарий postbuild будет запускаться после сценария сборки, потому что он имеет префикс «post». Поэтому, если я создам сценарии с именами prebuild, build и postbuild, они будут запускаться автоматически в том же порядке, когда я набираю `npm run build`.

Вы также можете разложить большие проблемы, вызвав один сценарий из другого:

  {
  "name": "npm-scripts-example",
  "версия": "1.0.0",
  "description": "Пример сценария npm",
  "scripts": {
    "clean": "rimraf ./dist && mkdir dist",
    "prebuild": "npm run clean",
    "build": "cross-env NODE_ENV = production webpack"
  }
}

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

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

А если команда становится слишком сложной, всегда можно вызвать отдельный файл:

  {
  "name": "npm-scripts-example",
  "версия": "1.0,0 ",
  "description": "Пример сценария npm",
  "scripts": {
    "build": "узел build.js"
  }
}

Я вызываю отдельный скрипт в задаче сборки выше. Этот сценарий будет запускаться Node и, таким образом, может использовать любые пакеты npm, которые мне нужны, и использовать всю мощь JavaScript внутри.

Я мог бы продолжить, но основные функции описаны здесь. Также есть небольшой курс Pluralsight по использованию npm в качестве инструмента сборки. Или посмотрите React Slingshot, чтобы увидеть все это в действии.

Заблуждение № 3: потоки Gulp необходимы для быстрых сборок

Gulp быстро завоевал популярность по сравнению с Grunt, потому что потоки в памяти Gulp быстрее, чем файловый подход Grunt. Но вам не нужен Gulp, чтобы насладиться мощью потоковой передачи. Фактически, потоковая передача всегда была встроена в командные строки как Unix, так и Windows. Оператор вертикальной черты (|) передает вывод одной команды на ввод другой команды. А оператор перенаправления (>) перенаправляет вывод в файл.

Так, например, в Unix я могу использовать grep для содержимого файла и перенаправлять вывод в новый файл:

  grep 'Cory House' bigFile.txt> linesThatHaveMyName.txt

Работа выше транслируется. Никакие промежуточные файлы не пишутся. (Хотите знать, как выполнить приведенную выше команду кроссплатформенным способом? Читайте дальше…)

Вы также можете использовать оператор `&` для одновременного запуска двух команд в Unix:

  npm run script1.js & npm run script2.js

Два приведенных выше сценария будут выполняться одновременно. Чтобы одновременно запускать скрипты на разных платформах, используйте npm-run-all. Это приводит к следующему заблуждению…

Заблуждение №4: скрипты npm не работают на разных платформах

Многие проекты привязаны к определенной операционной системе, поэтому кроссплатформенность не имеет значения. Но если вам нужно запустить кросс-платформенный, скрипты npm все равно могут отлично работать. Бесчисленные проекты с открытым исходным кодом тому подтверждение. Вот как.

Командная строка вашей операционной системы запускает сценарии npm. Итак, в Linux и OSX ваши сценарии npm запускаются из командной строки Unix. В Windows сценарии npm запускаются из командной строки Windows. Таким образом, если вы хотите, чтобы ваши сценарии сборки запускались на всех платформах, вам нужно сделать счастливыми и Unix, и Windows. Вот три подхода:

Подход 1: Используйте команды, которые работают на разных платформах. Существует удивительное количество кроссплатформенных команд. Вот несколько:

  && цепные задачи (запускать одну задачу за другой)
<содержимое входного файла для команды
> перенаправить вывод команды в файл
| перенаправить вывод команды на другую команду

Подход 2: Использовать пакеты узлов.Вы можете использовать пакеты узлов вместо команд оболочки. Например, используйте rimraf вместо rm -rf. Используйте cross-env, чтобы установить переменные среды кроссплатформенным способом. Найдите в Google, npm или libraries.io то, что вы хотите сделать, и почти наверняка найдется пакет узлов, который сделает это кроссплатформенным. И если ваши вызовы командной строки становятся слишком длинными, вы можете вызывать пакеты Node в отдельных сценариях, а также следующим образом:

  node scriptName.js

Приведенный выше сценарий представляет собой простой старый JavaScript, запускаемый Node.А поскольку вы просто вызываете сценарий из командной строки, вы не ограничены файлами .js. Вы можете запустить любой сценарий, который может выполнять ваша ОС, например Bash, Python, Ruby или Powershell.

Подход 3 : Используйте ShellJS. ShellJS — это пакет npm, который запускает команды Unix через Node. Таким образом, это дает вам возможность запускать команды Unix на всех платформах, включая Windows.

Я использовал комбинацию подходов №1 и №2 в React Slingshot.

Pain Point

По общему признанию, есть некоторые недостатки: спецификация JSON не поддерживает комментарии, поэтому вы не можете добавлять комментарии в пакет.json. Есть несколько способов обойти это ограничение:

Написать небольшие, хорошо названные, одноцелевые скрипты
Документировать скрипты отдельно (например, в README.md)
Вызвать отдельный файл .js

I предпочитаю вариант №1. Если вы разбиваете каждый сценарий на единственную ответственность, комментарии редко нужны. Имя скрипта должно полностью описывать цель, как и любая небольшая функция с хорошо названным именем. Как я уже говорил в «Чистом коде: написание кода для людей», небольшие функции единственной ответственности редко требуют комментариев.Когда я чувствую, что комментарий необходим, я использую вариант №3 и перемещаю сценарий в отдельный файл. Это дает мне всю композиционную мощь JavaScript, когда мне это нужно.

Package.json также не поддерживает переменные. Звучит как большая проблема, но не по двум причинам. Во-первых, наиболее распространенная потребность в переменных связана с окружением, которое вы можете установить в командной строке. Во-вторых, если вам нужны переменные по другим причинам, вы можете вызвать отдельный файл .js. Посмотрите на React-starter-kit элегантный пример этого паттерна.

Наконец, существует риск создания длинных и сложных аргументов командной строки, которые трудно понять. Проверка кода и тщательный рефакторинг — отличный способ убедиться, что сценарии npm разложены на небольшие, хорошо названные, одноцелевые функции, понятные каждому. Если он достаточно сложен, чтобы потребовать комментария, вам, вероятно, следует реорганизовать один сценарий в несколько сценариев с хорошо названными именами или извлечь его в отдельный файл.

Абстракции должны быть обоснованы

Gulp и Grunt — это абстракции над инструментами, которые я использую.Абстракции полезны, но у абстракций есть цена. Они протекают. Они делают нас зависимыми от разработчиков плагинов и их документации. И они добавляют сложности, увеличивая количество зависимостей. Я решил, что такие средства выполнения задач, как Gulp и Grunt, — это абстракции, которые мне больше не нужны.

Ищете подробности? Я расскажу, как создать процесс сборки с помощью сценариев npm с нуля в разделе «Создание среды разработки JavaScript» на Pluralsight.

Комментарии? Свяжитесь с нами ниже, на Reddit или Hacker News.

Наконец, я далеко не первый, кто это предлагает. Вот несколько отличных ссылок:

Кори Хаус является автором «React and Redux in ES6», «Clean Code: Writing Code for Humans» и множества других курсов по Pluralsight. Он является архитектором программного обеспечения в VinSolutions и обучает разработчиков программного обеспечения по всему миру таким методам разработки программного обеспечения, как фронтенд-разработка и чистое кодирование. Кори — Microsoft MVP, эксперт Telerik Developer и основатель outlierdeveloper.com.

глотков | WebStorm

WebStorm интегрируется с Gulp.js Task Runner. WebStorm анализирует файлы Gulpfile.js, распознает определения задач, отображает задачи в виде дерева, позволяет перемещаться между задачей в дереве и ее определением в файле Gulpfile.js, а также поддерживает выполнение и отладку задач.

Задачи Gulp.js можно запускать из дерева задач в специальном окне инструментов Gulp или из файла Gulpfile.js, запустив конфигурацию запуска Gulp.js, или как задачу перед запуском из другой конфигурации запуска.WebStorm показывает результат выполнения задачи в окне инструмента «Выполнить». Окно инструмента показывает вывод Grunt, сообщает о возникших ошибках, перечисляет пакеты или плагины, которые не были найдены, и т. Д. Имя последней выполненной задачи отображается в строке заголовка окна инструмента.

Перед тем, как начать

Убедитесь, что на вашем компьютере установлен Node.js.

Установка Gulp.js

Чтобы использовать Gulp в проекте WebStorm, вам понадобятся два пакета:

Глобально установленный пакет gulp-cli (интерфейс командной строки Gulp) для выполнения команд Gulp.
Пакет gulp, установленный в качестве зависимости разработки для построения дерева задач проекта и предоставления помощи при кодировании при редактировании файла Gulpfile.js. Узнайте больше о Gulpfile.js на официальном сайте Gulp.js.

Чтобы установить gulp-cli глобально

Во встроенном Терминале ( Alt + F12 ) введите:
npm install -global gulp-cli

Чтобы установить Gulp.js в project

Во встроенном терминале ( Alt + F12 ) введите:
npm install gulp --save-dev

Вы также можете установить пакеты на Node.js и NPM, как описано в npm, pnpm и Yarn.

Запуск задач Gulp.js из дерева задач

WebStorm позволяет легко и быстро запускать задачи Gulp.js прямо из дерева задач в окне инструмента Gulp. WebStorm автоматически создает временную конфигурацию запуска, которую вы можете сохранить и использовать позже при необходимости.

Gulp.js начинает построение дерева задач, как только вы вызываете Gulp.js, выбирая «Показать задачи Gulp» в контекстном меню Gulpfile.js в окне инструмента «Проект» или в Gulpfile.js открыт в редакторе. Дерево построено в соответствии с файлом Gulpfile.js, для которого был вызван Gulp.js. Если в вашем проекте несколько файлов Gulpfile.js, вы можете построить отдельное дерево задач для каждого из них и запускать задачи, не отказываясь от ранее построенных деревьев задач. Каждое дерево отображается под отдельным узлом.

Технически WebStorm вызывает Gulp.js и обрабатывает Gulpfile.js в соответствии с конфигурацией запуска Gulp.js по умолчанию. Делается это бесшумно и не требует никаких шагов с вашей стороны.

Чтобы открыть окно инструмента Gulp

Когда вы впервые строите дерево задач во время текущего сеанса WebStorm, окно инструмента Gulp еще не открывается.

По умолчанию WebStorm не распознает ES6 в Gulpfile.js и не может построить дерево задач. Чтобы решить эту проблему, обновите конфигурацию запуска Gulp.js по умолчанию.

Чтобы построить дерево задач из ES6 Gulpfile.js

В главном меню выберите.
В узле «Шаблоны» щелкните Gulp.js.
В открывшемся диалоговом окне «Конфигурация запуска / отладки: Gulp.js» введите --harmony в поле «Параметры узла» и нажмите «ОК».

Чтобы построить дерево задач из окна инструмента Gulp

В окне инструмента Gulp щелкните на панели инструментов и выберите нужный файл Gulpfile.js из списка. По умолчанию WebStorm показывает файл Gulpfile.js в корне вашего проекта.
Если у вас есть другой файл Gulpfile.js, нажмите Выбрать Gulpfile.js и выберите нужный файл Gulpfile.js в открывшемся диалоговом окне. WebStorm добавляет новый узел с путем к выбранному файлу Gulpfile.js в его заголовке и строит дерево задач под новым узлом.

Для восстановления дерева

Чтобы отсортировать задачи в дереве по их именам

Щелкните на панели инструментов, выберите «Сортировать по» в меню, а затем выберите «Имя».
По умолчанию дерево показывает задачи в том порядке, в котором они определены в Gulpfile.js (опция Порядок определения).

Для запуска задачи

Для запуска задачи по умолчанию

Для запуска нескольких задач

Для перехода к определению задачи

Запуск задач из Gulpfile.js

Поместите курсор на определение задачи. задачу, которую нужно запустить, и выберите в контекстном меню команду Выполнить <имя задачи>. WebStorm создает и запускает временную конфигурацию запуска с именем выбранной задачи.
Чтобы сохранить автоматически созданную временную конфигурацию запуска, поместите курсор на определение задачи, для которой он был создан, и выберите Сохранить <имя задачи> в контекстном меню выбора.

Запуск и отладка задач в соответствии с конфигурацией запуска

Помимо использования временных конфигураций запуска, которые WebStorm создает автоматически, вы можете создавать и запускать свои собственные конфигурации запуска Gulp.js.

Чтобы создать конфигурацию запуска Gulp.js

В главном меню выберите.
Щелкните на панели инструментов и выберите Gulp.js из списка. Откроется диалоговое окно «Запуск / отладка конфигурации: Gulp.js».
Укажите имя конфигурации запуска, задачи для запуска (используйте пробелы в качестве разделителей), расположение Gulpfile.js, в котором определены эти задачи, и путь к пакету gulp, установленному в корне текущего проекта.
Укажите интерпретатор Node.js для использования. Это может быть локальный интерпретатор Node.js или Node.js в подсистеме Windows для Linux.
При желании укажите переменные среды для Node.js и аргументы для выполнения задач. Используйте формат - <имя_параметра> <значение_параметра> , например: --env development . Узнайте больше на официальном сайте Gulp.

Для запуска задач

Для отладки задач

Создайте конфигурацию запуска / отладки Gulp.js, как описано выше.
Откройте файл Gulpfile.js в редакторе и при необходимости установите в нем точки останова.
Чтобы начать сеанс отладки, выберите необходимую конфигурацию отладки из списка на главной панели инструментов и щелкните рядом со списком или выберите в главном меню.
В открывшемся окне средства отладки проанализируйте выполнение приостановленной задачи, выполните пошаговое выполнение задачи и т. Д., Как описано в разделах «Проверка приостановленной программы» и «Пошаговое выполнение программы».

Чтобы запустить задачу Gulp как задачу перед запуском

Откройте диалоговое окно «Запуск / отладка конфигураций», выбрав в главном меню, и выберите нужную конфигурацию из списка или создайте ее заново, щелкнув и выбрав значок соответствующий тип конфигурации запуска.
В открывшемся диалоговом окне щелкните в области «Перед запуском» и выберите из списка «Запустить задачу Gulp».
В открывшемся диалоговом окне задачи Gulp укажите Gulpfile.js, где определена требуемая задача, выберите задачу для выполнения и укажите аргументы для передачи инструменту Gulp.
Укажите расположение интерпретатора Node.js, передаваемые ему параметры и путь к пакету gulp.

Автоматический запуск задач Gulp.js

Если у вас есть задачи, которые вы запускаете на регулярной основе, вы можете добавить соответствующие конфигурации запуска в список задач запуска. Задачи будут выполняться автоматически при запуске проекта.

В диалоговом окне «Параметры / настройки» Ctrl + Alt + S щелкните «Задачи при запуске» в разделе «Инструменты».
На открывшейся странице Startup Tasks щелкните на панели инструментов.
Из списка выберите необходимую конфигурацию запуска Gulp.js. Конфигурация добавлена в список.
Если в проекте нет подходящей конфигурации, щелкните и выберите «Редактировать конфигурации». Затем определите конфигурацию с необходимыми настройками в Run / Debug Configuration: Gulp.js открывается страница. При сохранении новой конфигурации она автоматически добавляется в список задач запуска.

Последнее изменение: 26 мая 2021 г.

Gulp и Webpack: лучшее из обоих миров

Однажды я сказал вам, что Webpack — отличный инструмент для управления JavaScript в ваших веб-проектах.Это связано с тем, что Webpack позволяет писать модульный JavaScript для браузера и обрабатывает разрешение зависимостей и объединение файлов. Я сравнил Webpack с Gulp, потоковым процессором и утилитой для запуска задач, которая, хотя и имеет свое место, не выполняет сложную компоновку модулей, как это делает Webpack. Это делает Gulp менее привлекательным вариантом для упаковки файлов JavaScript.

Одна проблема с любым конвейером ресурсов, однако, возникает при его использовании вместе с генератором статических сайтов. У вас есть один инструмент для создания JavaScript и CSS, а другой инструмент для создания HTML-кода вашего сайта.По большей части это довольно незначительное неудобство: ваш сценарий развертывания может просто запускать команды отдельно, и, возможно, в вашей среде разработки вы можете запускать команду Webpack watch и сервер разработки SSG в отдельных окнах терминала. Немного неэлегантное решение, но вполне работоспособное.

Многие разработчики нашли творческие решения этой проблемы, о чем я узнал во время бета-тестирования нашей новой функции Instant Previews. С помощью Instant Previews Forestry может запускать сервер разработки вашего генератора статических сайтов в нашей облачной среде предварительного просмотра, значительно сокращая время, необходимое для восстановления вашего предварительного просмотра.К сожалению, некоторые из тех несовершенных, но пригодных к использованию решений , которые работали в среде предварительного просмотра разработчиков, не так хорошо работают с мгновенным предварительным просмотром — выполнение нескольких команд непросто, а несколько параллельных команд могут привести к состояниям гонки.

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

Мы снова встречаемся, старый друг.

Конечно, Gulp здесь идеально подходит.

Прежде чем мы продолжим, сделайте глубокий вдох. Я начал ту статью в Webpack, в которой обсуждалась усталость инструмента, поэтому я могу представить, что вы чувствуете прямо сейчас: Мне нужен другой инструмент сборки для запуска моего инструмента сборки?

Это будет действительно простой , я обещаю.

Начало работы с Gulp

Для целей этого руководства предположим, что у вас есть сайт Hugo, который использует Webpack для создания ресурсов.Если вы используете другой генератор статических сайтов, такой как Jekyll, продолжайте читать: его легко адаптировать к нескольким различным SSG.

Поскольку у вас уже настроена сборка Webpack, можно с уверенностью предположить, что у вас уже есть Node и NPM в вашей среде, и в вашем проекте уже есть файл package.json с вашими зависимостями Webpack. Чтобы добавить Gulp в свой проект, просто установите его через NPM, например:

В этом руководстве используется последняя версия Gulp — 4.0,0 на момент написания. Если вы читаете это в будущем и столкнетесь с проблемами, вы можете убедиться, что используете совместимую версию Gulp:

  npm install --save [email protected]

Создание задач

Мы собираемся определить серию задач, которые будут запускать все основные компоненты нашей сборки, одну за другой. В конечном итоге мы создадим две команды Gulp: команду build , которая построит наш сайт для развертывания, и команду develop , которая запустит сервер разработки, который перестраивает и перезагружает сайт в ответ на изменения.

Для команды build потребуется две задачи:

Создайте ресурсы Webpack
Запустите генератор статического сайта

Команда develop будет аналогична команде build, но с парой дополнительных шагов:

Создайте ресурсы Webpack
Запустите генератор статического сайта
Запустить сервер разработки
Наблюдайте за изменениями файлов, повторно запускайте сборки и перезагружайте сервер разработки

После установки Gulp создайте новый файл с именем gulpfile.js в корне вашего репозитория. Вверху этого файла добавьте следующую строку для загрузки пакета gulp для загрузки gulp в этот контекст:

  const gulp = require ("gulp")

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

  function someTask (cb) {
    // делаем кое-что
    cb ()
}

В качестве альтернативы вы можете просто заключить свой код в обещание :

  function someTask (cb) {
    вернуть новое обещание ((разрешить, отклонить) => {
        // делаем кое-что
        разрешить()
    })
}

Чтобы запустить эту задачу в командной строке, вам необходимо экспортировать ее:

  экспорт.someTask = someTask

После этого вы можете выполнить задачу с помощью следующей команды:

Если Gulp не установлен глобально, выполнение команды gulp может не сработать. В конце концов, мы собираемся запустить нашу команду gulp как сценарий NPM, который правильно определит путь к нашим установленным модулям, так что это не проблема.

Настройка конвейера сборки

Для начала настроим основной конвейер сборки.Это просто запустит сборку Webpack и подождет, пока ресурсы будут сгенерированы, прежде чем запускать сборку SSG. Мы можем использовать gulp.series , чтобы создать новую задачу для последовательного выполнения этих двух подзадач, а затем экспортировать ее, чтобы мы могли запустить ее из командной строки. Структура gulpfile.js будет выглядеть примерно так:

  const gulp = require ('глоток')

function assets (cb) {
    // запускаем webpack
}
function ssg (cb) {
    // запускаем команду SSG
}

// экспортируем задачу сборки, которая последовательно запускает две указанные выше задачи
экспорт.build = gulp.series (активы, ssg)

Создание задачи Webpack

К счастью для нас, у Webpack есть API-интерфейс Node, который позволяет нам вызывать его из среды Node, поэтому включить его в задачу Gulp будет очень просто.

Во-первых, потребуется модуль webpack в gulpfile.js (если вы добавляете его в существующий проект Webpack, у вас уже будет установлен Webpack).

  const webpack = require ('webpack')
const webpackConfig = require ('./webpack.config.js ')

Вы заметите, что мы также загружаем конфигурацию Webpack. Если ваша конфигурация Webpack находится не в webpack.config.js в корне вашего проекта, вам нужно изменить путь в приведенном выше коде.

Чтобы запустить Webpack, нам просто нужно вызвать функцию webpack из модуля и передать ей наш webpackConfig . Однако, чтобы это работало с Gulp, мы должны заключить его в Promise, который может обрабатывать состояния успеха и ошибки:

  функциональные активы (cb) {
    вернуть новое обещание ((разрешить, отклонить) => {
        webpack (webpackConfig, (err, stats) => {
            if (err) {
                возврат отклонить (ошибка)
            }
            если (статистика.hasErrors ()) {
                возврат отклонить (новая ошибка (stats.compilation.errors.join ('\ n')))
            }
            разрешить()
        })
    })
}

Вот и все! Прелесть этого решения в том, что оно будет работать с любой конфигурацией Webpack, и если вы обновляете свой конвейер ресурсов, вам не нужно вносить какие-либо изменения в этот файл.

Создание задачи SSG

Hugo, конечно, не имеет Node API, но мы можем разумно предположить, что мы собираемся запустить нашу сборку в среде, которая имеет доступ к команде hugo , мы будем использовать встроенный в Node модуль child_process для запуска процесса hugo , как если бы мы вызывали его из командной строки.

Мы собираемся использовать функцию execFile модуля child_process . Для достижения наилучших результатов было бы замечательно, если бы мы могли заставить execFile возвращать Promise. К счастью, мы можем использовать utils.promisify , чтобы предоставить версию функции, которая делает именно это. Добавьте следующие строки в начало файла gulpfile.js с остальной частью вашего импорта:

  const util = require ('утилита')
const execFile = util.promisify (требуется ('дочерний_процесс').execFile)

Тогда все, что вам нужно сделать для реализации функции ssg , это:

  function ssg (cb) {
    вернуть execFile ('hugo')
}

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

  function ssg (env) {
    if (env === 'production') {
        вернуть hugo = cb => execFile ('hugo')
    }
    return hugo = cb => execFile ('hugo', ['-D', '- F'])
}

Если приведенный выше код выглядит немного странно, на то есть веская причина. Вы можете просто вернуть cb => execFile ('hugo') без ненужного присваивания, но вывод Gulp в терминале идентифицирует задачи по имени их функции. Таким образом, при назначении функции стрелки перед ее возвратом имя задачи будет отображаться в терминале как hugo (в отличие от ).

С этой модификацией нам нужно изменить нашу задачу build . Поскольку функция ssg теперь возвращает задачу Gulp, вместо того, чтобы быть самой задачей Gulp, мы изменим строку с

  exports.build = gulp.series (assets, ssg)

по

  exports.build = gulp.series (assets, ssg ('production'))

Добавление сценария NPM

Как упоминалось ранее, рекомендуется запускать эти задачи в виде сценария NPM, поскольку в этом случае он может автоматически разрешить любые локально установленные модули.Мы сделаем это, добавив раздел scripts в package.json . Если у вас уже есть раздел сценариев в этом файле, не стесняйтесь добавлять или изменять там команды.

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

После добавления сценария его можно вызвать из командной строки с помощью команды npm run :

Настройка конвейера разработки

Теперь, когда мы разработали базовый конвейер сборки, осталось всего пара шагов, чтобы добавить сервер разработки с динамической перезагрузкой.Вместо того, чтобы использовать hugo serve , мы собираемся продолжить создание сайта с помощью команды hugo и запустить сервер разработки через Gulp.

Browsersync

Для запуска нашего сервера разработки мы будем использовать BrowserSync. Сначала установите его:

  npm install --save browser-sync

Затем загрузите его вверху gulpfile.js с остальными импортированными файлами:

  const browserSync = require ('browser-sync').Создайте()

Наконец, мы создадим новую задачу Gulp под названием serve , которая запускает сервер BrowserSync, вызывая его функцию init . Второй параметр, переданный в init , — это функция обратного вызова, которая запускается, когда сервер будет готов, поэтому мы передадим функцию сигнала Gulp в качестве обратного вызова.

  function serve (cb) {
    browserSync.init ({
        сервер: "./public",
        порт: 8080,
        хост: "0.0.0.0"
    }, cb)
}

Потому что команда hugo построит наш сайт до ./ public , мы установили это как корень документов нашего сервера. Если вы используете другой SSG или создаете свой сайт в другом каталоге, вы захотите изменить это.

Мы выбрали привязку к 0.0.0.0:8080 здесь для совместимости с мгновенным предварительным просмотром Forestry.

Дополнительно создадим задачу на перезагрузку сервера:

  функция перезагрузки (cb) {
    browserSync.reload ()
    cb ()
}

Живая перезарядка

Мы можем использовать функцию Gulp watch , чтобы отслеживать изменения файлов и запускать задачу в ответ:

  функция часы (CB) {
    вернуть глоток.смотреть(
        '** / *', // все смотрим ...
        {
            игнорируется: [
                // ... кроме вещей, созданных в процессе сборки.
                'public / ** / *',
                'статические / активы / ** / *'
            ]
        },
        // когда что-то меняется, перестраиваем + перезагружаем
        gulp.series (активы, ssg ('разработка'), перезагрузить)
    )
}

Здесь важно обратить внимание на пару вещей:

Чтобы просмотреть все файлы в проекте, мы можем просто использовать этот шаблон globstar : ** / *
Мы хотим обязательно игнорировать любые файлы, созданные в процессе сборки, иначе мы можем попасть в бесконечный цикл перезагрузки.Для нашего проекта это означает игнорирование всего в public (где построен сайт), а также всего в static / assets (где генерируются активы). В зависимости от того, как настроен ваш сайт, вам может потребоваться чтобы настроить эти правила.

Теперь, когда это сделано, нам просто нужно создать и экспортировать задачу develop , выполнив следующую серию:

  exports.develop = gulp.series (assets, ssg ('development'), serve, watch)

Это запустит начальную сборку, запустит сервер BrowserSync, а затем проследит за изменениями файлов, запустив последовательность восстановления и перезагрузки, определенную в нашей задаче watch .

Осталось добавить соответствующий скрипт NPM:

  {
    ...
    "scripts": {
        "build": "gulp build",
        "develop": "глоток развить"
    }
}

Теперь, когда мы запускаем npm run develop , он запускает сервер разработки, собирая как ресурсы Webpack, так и сайт Hugo в единой последовательности. При использовании сайта с мгновенным предварительным просмотром Forestry вы можете просто установить команду мгновенного предварительного просмотра на npm run develop .

Gulp, а? Отлично!

Мудрость заключается в использовании правильного инструмента для работы. Отнесение Gulp и Webpack к «инструментам сборки» покажется излишним для использования обоих, но в этом случае они отлично работают вместе. Я уже объяснял, почему мне нравится использовать Webpack, но вот что мне нравится в этом конкретном решении Gulp:

Работает с любым генератором статических сайтов, который может работать в вашем терминале
Работает с различными конфигами Webpack без модификации
Добавляет BrowserSync и динамическую перезагрузку к любому SSG
Упрощает работу с функцией мгновенного просмотра Forestry

Вы можете загрузить весь файл gulpfile .js из этой сущности. Если вы не используете Hugo, все равно будет довольно просто адаптировать его к любому SSG, который вы используете.

И на этом все, что осталось сказать: хорошо, увидимся позже!

Gulp против Grunt: различие между двумя исполнителями задач

На первый взгляд, Grunt и Gulp не сильно отличаются друг от друга по своим основным функциям; оба инструмента автоматизации доступны по лицензии MIT, поэтому исходный код открыт, и находится в свободном доступе.Оба приложения могут управляться из командной строки и иметь собственный интерфейс, установленный вместе с ним. Исполнители задач также используют тот же диспетчер пакетов, npm . Благодаря большим каталогам плагинов, Grunt и Gulp могут легко автоматизировать огромное количество задач . Если для желаемого процесса нет расширений, их можно запрограммировать с помощью обоих инструментов, хотя из-за сложной структуры для обоих исполнителей задач требуется знаний JavaScript и узла.js .

Однако, в то время как Gulp в основном основан на потоке модуля node.js, Grunt в основном использует модуль fs (файловая система), который подчеркивает одно из наиболее важных различий между двумя инструментами: Grunt строго ориентирован на файлы, и создает временные локальные файлы во время выполнения задач. Gulp , с другой стороны, обрабатывает процессы через память и немедленно записывает их в целевой файл, что дает программе преимущество в скорости.

Второй отличительной чертой является соответствующая концепция обоих решений. Программирование и структура Grunt дают пользователям некоторое направление; выполненных задач, расположенных там, уже определены , и их нужно просто настроить. Для сравнения, Gulp предоставляет гораздо больше места для независимого программирования, поскольку предоставляет только отдельные модули . Хотя, с одной стороны, это упрощает понимание предыстории и контекста, это также требует от пользователя гораздо большего.Чем крупнее проект, тем больше в игру сильных сторон Gulp входит , поэтому теперь стал первым выбором для многих людей . Однако, благодаря более низким требованиям, Grunt по-прежнему является ценным инструментом для небольших управляемых проектов .

Введение в Gulp JS

Gulp JS предоставляет возможность работать со статическими файлами ресурсов, обычно обрабатывает файлы перед их выводом в браузер. В этой статье вы узнаете, как использовать Gulp JS, чтобы изменить процесс разработки, чтобы сделать разработку более эффективной и простой.

Что такое Gulp JS?

Gulp JS — это, по сути, средство выполнения задач с открытым исходным кодом для приложения JavaScript. Gulp — это средство выполнения задач / сборки для архитектур на основе JavaScript. Gulp — это модуль npm, который прост в использовании и управлении. Есть несколько готовых задач, которые вы можете найти в репозиториях GitHub.

Gulp можно подключить к любому веб-приложению, так же как и к Angular JS, React JS или любой архитектуре Javascript.

Gulp JS — это автоматическая программа запуска задач Nodejs для построения кода во интерфейсной разработке и построитель проектов автоматизации.Gulp не только оптимизирует ресурсы веб-сайта, но и помогает автоматически выполнять множество повторяющихся задач. Кроме того, это значительно повышает эффективность работы.

Gulp JS не является библиотекой или фреймворками, такими как ReactJS или AngularJS. Это просто набор инструментов для создания приложений Javascript.

Зачем нужен Gulp JS?

Есть некоторые проблемы, которые разработчик обнаруживает при разработке приложения на Javascript. Gulp в основном используется для длительных и повторяющихся задач. Gulp легко справятся со всеми надоедливыми задачами с помощью плагинов и задач.

Характеристики:

Это основные функции, которые предоставляет Gulp JS:

Легко учиться
Эффективно
Легко использовать
Высокое качество

Как установить Gulp

Вы можете установить Gulp из командной строки. Для установки Gulp используется одна команда npm (Node Package Manager). Здесь я выполняю глобальную установку gulp, в которой gulp глобально доступен для всех приложений на вашем сервере.

Предварительные требования

Наиболее важным является то, что вам необходимо настроить среду Node и для этого установить node js и npm на вашем сервере для использования Gulp.

$ npm install -global-gulp-cli

После выполнения вышеуказанной команды, если вы хотите увидеть, правильно ли установлен gulp, вы можете выполнить следующую команду.

Эта команда вернет номер версии gulp, если он установлен.

Затем вам необходимо установить gulp локально в проект

npm install —-save-dev gulp

Здесь —-save-dev используется для обновления пакета.json и обновите значение dev-dependencies, чтобы указать, что проект должен зависеть от gulp.

Требования к структуре каталогов

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

Давайте посмотрим на структуру каталогов.

dist
| __ app.css
| __ app.js
src
| __ app.css
| __ app.js
gulpfile.js

Основная идея — использовать gulpfile.js для распределения задач в отдельных документах. Это самый простой способ управлять каждой задачей в одном файле.

Папка Src будет содержать исходный код приложения до его компиляции. После компиляции с использованием Gulp вся задача и код будут помещены в каталог dist. Вам нужен файл gulpfile.js в корневом каталоге, и это единственный файл, который вам нужен для использования Gulp. Этот файл описывает все задачи и все, что вы хотите, чтобы gulp делал.

Как работает Gulp?

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

Каковы общие задачи Gulp?

Gulp и grunt очень похожи, но написать задачу в Gulp очень легко, поэтому люди переходят от grunt к Gulp.Если вы проверяете задачу в Grunt, ее очень сложно понять и написать. Давайте разберемся с задачами Gulp:

Очистить
Concat
Uglify
Часы и синхронизация браузера

Давайте приступим к пониманию задачи по очереди.

1. Очистить

Задача очистки в основном используется для очистки файлов и каталогов с помощью Gulp.

var gulp = require (‘gulp’);

var clean = require (‘gulp-clean’);

гл.задача (‘очистка’, функция () {

return gulp.src (‘сборка’, {чтение: ложь}). pipe (clean ());

});

Здесь включены два модуля, один — gulp, а другой — gulp-clean. gulp.task позволяет вам определить задачу. Gulp clean используется для очистки вашего каталога. Clean — это имя задачи в gulp.task. Вместо очистки вы также можете очистить. Есть функция gulp.src, в которой нужно передать путь к каталогу. Pipe вернет те файлы gulp, которые находятся в указанном каталоге, и запустите команду clean.

gulp.src используется для указания исходных файлов. Есть еще одна функция gulp.dest, которая предназначена для папки назначения для вывода файлов.

2. Concat

Задача Concat в основном доступна для объединения файлов или кода.

var gulp = require (‘gulp’);

var concat = require (‘gulp-concat’);

gulp.task (‘vendor’, function () {

return gulp.src (‘vendor / *. Js’). Pipe (concat (‘vendor.js ‘)). pipe (gulp.dest (‘ build / vendor.js ‘));

});

Здесь gulp.src берет файл из исходного каталога, объединяет все файлы в vendor.js и помещает его в папку назначения, которая находится в сборке.

Если вы изменили свои зависимости, вам необходимо внести изменения в файлы поставщиков. Вы можете использовать команду concat, чтобы прикрепить новые файлы зависимостей в vendor.js. В противном случае вы можете сначала выполнить gulp.clean, а затем gulp.build, он будет делать то же самое, но это утомительная задача, потому что требуется несколько минут, чтобы взять все файлы javascript и поместить их в один файл.Так что команда concat — лучший вариант.

3. Uglify

Uglify — это углификация вашего кода. Это минификация скриптов и стилей. Uglification удаляет все пробелы, символы новой строки и комментарии из файлов и делает их намного легче, что внутренне делает ваше приложение быстрее. Итак, Gulp очень легко справляется с этим с помощью gulp.uglify.

var gulp = require (‘gulp’);

var concat = require (‘gulp-concat’);

var uglify = require (‘gulp-uglify’);

гл.задача (‘поставщик’, функция () {

return gulp.src (‘vendor / *. js’). pipe (concat (‘vendor.js’)). pipe (uglify ()). pipe (gulp.dest (‘build / vendor.js’));

});

gulp.dest () используется для записи потока с использованием файла src. Он также создает файл и после создания файла продолжает передавать поток для других операций.

Здесь сначала определите исходный путь с помощью gulp.src, а затем по конвейеру для удаления файлов и поместите его в место назначения с помощью gulp.dest.

4. Смотреть

var gulp = require (‘gulp’);

var watch = require (‘gulp-watch’)

gulp.task (‘serve’, [‘watch’], function () {

browserSync.init ({

path.join (conf. paths.tmp, ‘/ serve’), conf.paths.src);

});

Часы будут постоянно следить за файлами, поэтому, если вы измените любой файл, который находится в часах, они перейдут к списку изменений и выполнят действие.Служить — это имя задачи в этом. browserSync синхронизирует просматриваемый файл с местом назначения, если будут внесены какие-либо изменения.

Вот и все !! Надеюсь, вы, ребята, узнаете что-нибудь из этой статьи о gulp, и, надеюсь, вы будете использовать Gulp в своем следующем проекте.

Задача сборки и выпуска

Gulp — Azure Pipelines

17.12.2019
2 минуты на чтение

В этой статье

Azure Pipelines | Azure DevOps Server 2020 | Сервер Azure DevOps 2019 | TFS 2018 — TFS 2015

Используйте эту задачу для запуска задач gulp с помощью Node.js потоковая система сборки на основе задач.

Требования

глоток

Фрагмент YAML

  # глоток
# Запускаем gulp Node.js систему сборки на основе задач потоковой передачи
- задача: глоток @ 1
  входы:
    #gulpFile: 'gulpfile.js'
    #targets: # Необязательно
    #arguments: # Необязательно
    #workingDirectory: # Необязательно
    #gulpjs: # Необязательно
    #publishJUnitResults: false # Необязательно
    #testResultsFiles: '** / TEST - *. xml' # Требуется, если publishJUnitResults == True
    #testRunTitle: # Необязательно
    #enableCodeCoverage: false
    #testFramework: 'Mocha' # Необязательно.Варианты: мокко, жасмин
    #srcFiles: # Необязательно
    #testFiles: 'test / *. js' # Требуется, если enableCodeCoverage == True

Аргументы

Аргумент	Описание
`gulpFile` gulp Путь к файлу	(Обязательно) Относительный путь от корня репо скрипта файла gulp, который вы хотите запустить. Значение по умолчанию: gulpfile.js
`целей` залпом Задачи	(Необязательно) Список выполняемых задач, разделенный пробелами.Если не указан, будет запущена задача по умолчанию.
`аргументы` аргументы	В gulp переданы дополнительные аргументы. Совет: —gulpfile не нужен, так как уже добавлен через ввод gulpFile выше
`cwd` Рабочий каталог	(Необязательно) Текущий рабочий каталог при запуске сценария. По умолчанию используется папка, в которой находится сценарий. Псевдонимы аргументов: `workingDirectory`
`gulpjs` gulp.js расположение	(Необязательно) Путь к альтернативному файлу gulp.js относительно рабочего каталога. Псевдонимы аргументов: `workingDirectory`
`publishJUnitResults` Опубликовать в Azure Pipelines	Выберите этот параметр, чтобы опубликовать результаты теста JUnit, полученные с помощью сборки gulp, в Azure Pipelines. Значение по умолчанию: false
`testResultsFiles` Test Results Files	(Обязательно) Путь к файлам результатов тестирования.Можно использовать подстановочные знаки. Например, ** / TEST — . Xml для всех файлов XML, имя которых начинается с TEST-. Значение по умолчанию: * / TEST — *. Xml
`testRunTitle` Test Run Title	(Необязательно) Введите имя для тестового прогона
`enableCodeCoverage` Включить покрытие кода	(Необязательно) Выберите этот параметр, чтобы включить покрытие кода с использованием Стамбула Значение по умолчанию: false
`testFramework` Test Framework	(Необязательно) Выберите свою тестовую среду Значение по умолчанию: Mocha
`srcFiles` Исходные файлы	(Необязательно) Укажите путь к исходным файлам, которые вы хотите перехватитьRequire ()
`testFiles` Test Script Files	(обязательно) Укажите путь к файлам тестовых сценариев. Значение по умолчанию: test / *.js

Пример

Запустите gulp.js

На вкладке «Сборка»:

Упаковка: npm

Установите npm.

Сборка: gulp

Запустите ваш сценарий.

путь к файлу gulp: gulpfile.js
Advanced, gulp.js расположение: node_modules / gulp / bin / gulp.js

Создайте узел.js приложение

Создайте приложение Node.js с помощью gulp

Открытый исходный код

Эта задача с открытым исходным кодом на GitHub. Отзывы и предложения приветствуются.

FAQ

Нужен ли мне агент?

Для запуска сборки или выпуска необходим хотя бы один агент.

У меня проблемы. Как я могу их устранить?

См. Устранение неполадок при сборке и выпуске.

Я не могу выбрать пул агентов по умолчанию и не могу поставить свою сборку или выпуск в очередь. Как это исправить?

См. Пулы агентов.

Моя задача push NuGet завершается ошибкой из-за следующей ошибки: «Ошибка: невозможно получить сертификат локального эмитента». Как я могу это исправить?

Это можно исправить, добавив доверенный корневой сертификат. Вы можете либо добавить переменную среды NODE_EXTRA_CA_CERTS = file в свой агент сборки, либо добавить в конвейер переменную задачи NODE.EXTRA.CA.CERTS = file . Подробнее см. Переменные среды.

Gulp.js и Webpack — что использовать и когда?

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

Это потому, что мы, как веб-разработчики, больше не работаем только с HTML-кодом. Вместо этого акцент смещается на сложные приложения, которые можно развернуть для самых разных целей — управление данными, одностраничные приложения, PWA и т. Д.!

Итак, когда речь идет, в частности, о разработке на JavaScript, в нашем распоряжении есть ряд инструментов, облегчающих жизнь.Среди таких инструментов особенно выделяются два имени — gulp.js (обычно называемый gulp) и webpack.

В этой статье мы узнаем больше о gulp и webpack, а также поймем, как любой из них может помочь нам в нашем рабочем процессе разработки.

gulp.js

Проще говоря, gulp — это система потоковой сборки, которая может помочь нам автоматизировать несколько задач. Другими словами, мы можем использовать gulp, чтобы заботиться об общих действиях и задачах, которые в остальном важны и почти всегда выполняются, но повторное выполнение одного и того же, как правило, отнимает у нас много времени.

И когда мы говорим о «задачах», мы имеем в виду такие действия, как минификация кода CSS или JS, компиляция файлов SASS или LESS, преобразование значков SVG в шрифты, отслеживание изменений файлов и другие действия и т. Д.

Используя gulp, мы можем автоматизировать такие задачи. Естественно, это может существенно сэкономить наше время. Задачи Gulp — это простые асинхронные функции JS, которые принимают обратные вызовы при первой ошибке.

Узнайте больше о gulp здесь.

webpack

webpack — это сборщик модулей для JavaScript.Это означает, что он может принимать модули с зависимостями, а затем генерировать статические активы, которые являются представителями указанных модулей.

Учитывая тот факт, что webpack является сборщиком модулей, в идеале он может работать бок о бок с средством выполнения задач, таким как gulp.js

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

В результате webpack теперь вырос за пределы своего прежнего уровня и часто используется для замены таких инструментов, как gulp.js, когда используется вместе с его плагинами.

Проще говоря, webpack принимает несколько модулей с зависимостями. Это могут быть файлы PNG, сценарии SASS и CSS, другие форматы изображений и файлов мультимедиа и т. Д.Затем webpack связывает их, чтобы получить согласованные статические ресурсы, которые мы можем развернуть за считанные минуты.

Узнайте больше о webpack здесь.

Используете webpack или gulp.js?

Хотя gulp.js и webpack представляют собой разные виды инструментов, в настоящее время они служат более или менее схожей цели. Таким образом, многие разработчики JavaScript часто заменяют gulp.js на webpack и используют последний в качестве основного инструмента для повышения производительности и лучшего управления рабочим процессом.

Это, очевидно, больше основанное на практике наблюдение, и фактический пробег может варьироваться от одного кодера к другому. В результате очень мало доказательств того, что gulp.js является второстепенным инструментом по сравнению с webpack, или наоборот. Фактически, webpack — это связыватель модулей, тогда как gulp.js — это средство выполнения задач — само это определение подразумевает, что мы можем использовать оба инструмента в согласии друг с другом без каких-либо конфликтов.

Но из-за широкого набора функций webpack многие разработчики используют webpack как замену gulp.js — webpack предоставляет решения и настройки для минификации и сопоставления источников, а в некоторых случаях может даже запускаться как промежуточное ПО. На самом деле, кроме модульного тестирования и линтинга, webpack мало что может сделать. Вот почему использование webpack может помочь нам избавиться от дополнительных проблем, связанных с добавлением gulp.js в наши проекты.

Тем не менее, стоит отметить, что gulp.js гораздо проще настраивать и настраивать по сравнению с webpack. Это делает gulp.js более разумным и очевидным выбором для многих начинающих разработчиков.Однако, несмотря на то, что его проще настроить, gulp.js также может быть адаптирован для более крупных и сложных рабочих процессов, если и когда это необходимо.

Заключение

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

В зависимости от характера проекта, над которым мы работаем, а также от наших основных требований, мы можем выбрать любой из двух.Например, если мы фокусируемся только на кодировании, нам может понадобиться средство выполнения задач, и в таких случаях gulp.js — лучший выбор для нас. С другой стороны, если все, что нам нужно сделать, это настроить и настроить, возможно, связыватель модулей, такой как webpack, больше подходит для наших нужд.

Наконец, стоит отметить, что наш выбор никоим образом не ограничивается только gulp.js или webpack. В распоряжении разработчиков JavaScript есть множество других инструментов, таких как Browserify, Brunch и другие.