Как настроить webpack для верстки

Как я разбирался с Webpack. Настройка на примере SCSS.

Как ни странно, детально разобраться с вебпаком я захотел именно для того, чтобы использовать в своих проектах CSS-пропроцессоры. Даже когда появился Gutenberg, я в это решил не вникать и создавал блоки для него на чистом JS 😁

В этом уроке постараюсь рассказать всё пошагово и очень легко, для тех, кто никогда не работал ни с чем из этого, но очень хочет. Начнём с настройки Node.js, потом перейдём к установке Webpack, и только потом уже установим необходимые для работы с SCSS препроцессором модули, также настроим минификацию.

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

1. Node.js

1.1 Установка

Всё начинается очень легко – нужно перейти на сайт nodejs.org и скачать её как обычную прогу.

Проверяем, что всё установилось, для этого открываем Терминал (у меня Mac OS) и попробуем прочекать версию node.js: node -v

1.2 Инициализируем проект

Для этого открываем терминал в папке с проектом (это лучше сделать через текстовый редактор, который вы используете, я например установил пакет для Atom для работы с терминалом и всё) и запускаем там npm init , после чего будут появляться различные вопросы, например как назвать ваш проект, какая у него версия и т.д

• package name – название проекта (по умолчнию – название папки проекта),
• version – версия (по умолчанию 1.0.0),
• description – описание проекта,
• entry point – типо основной файл вашего npm-проекта, который и будет запускаться при его сборке, это нам пока не понадобится, можно оставить значение по умолчанию (по умолчанию index.js),
• test command – команда, которая будет происходить при запуске npm run test , оставляем значение по умолчанию,
• git repository и keywords не понадобится,
• author – легко, имя автора,
• license – лицензия, (по умолчанию ISC),

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

2. Установка Webpack

2.1 Установка

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

Для установки webpack для проекта, там же, в терминале запускаем npm install webpack -D . Ключ -D означает, что webpack нам нужен только при разработке, но не нужен в рабочей версии проекта.

После выполнения команды запустится установка, после установки произойдёт вот что:

• В файле package.json в devDependencies появится «webpack»: «^версия» ,
• В проекте с темой появится папка node_modules , там будут лежать файлы модуля вебпак. Когда потом будете переносить ваш плагин/тему на живой сайт, очень прошу, не переносите эту папку!! 🤦‍♂️

После установки также откройте файл package.json и добавьте в параметр scripts следующее:

• Когда в консоли будете писать npm run build – у вас будет запускаться сборка проекта.
• Если напишете npm run start – webpack начнём мониторить изменения файлов и осуществлять сборку после сохранения.

2.2 Конфигурация webpack.config.js

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

Напоминаю, что наша цель вебпака в этом уроке – чтобы он собирал нам скрипты в scripts.js , и файл style.css из файлов sass. Т е есть файлы на входе и на выходе. И в webpack.config.js мы как раз это и прописываем.

• entry (строка 4) – ничего общего с index.js из шага 1.2. Это входной JS файл, в который будут подключаться все остальные, он находится в папке src . Тут ничего придумывать не нужно – всё стандартно.
• output (строка 5) – то, где создавать файл результата выполнения сборки. У меня это assets/script.js , но стандартно обычно для этого используется директория dist .

В принципе можете создать все необходимые директории и файлы, а также index.php (у нас же тема WordPress) и подключить в неё файл scripts.js

2.3 Проверяем, что на этом этапе webpack работает

Суть проверки будет заключаться в том, что я создам два JS файла с каким-то изишным кодом, подключу их в index.js , запущу вебпак и проверю, что произойдёт на сайте.

Итак, я создаю два файла test.js и test_1.js , которые располагаются в папке /src/js . В каждый из них я запишу по одной строчке кода, например console.log( ‘какой-то текст’ ) .

Затем в файле index.js я их подключаю следующим образом:

После этого открываю терминал для проекта и запускаю сборку npm run build . Теперь, если правильно подключили файл scripts.js на вашем сайте, то в консоли браузера у вас должны появиться два сообщения.

Если проводить параллель с темой или плагином WordPress, то я бы использовал сборку непосредственно для той части кода, в которой я планирую работать с Gutenberg, React. Собирать лёгкий jQuery-код для самого сайта нет смысла. Про настройку JSX я наверное ещё напишу отдельно.

3. SCSS

3.1 Как это будет

Сначала давайте немного наглядности, чтобы вам было понятно. Точно так же, как и с JS файлами, давайте проделаем следующее:

1. Создаем директорию /src/scss и добавим в неё файл main.scss ,
2. Одна из фишек препроцессоров – переменные, поэтому содержимое файла закинем такое:

3. Подключим наш файл main.scss там же – в index.js – import ‘./scss/main.scss’; ,
4. Файл style.css в папке с темой у нас уже создан

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

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

3.1 Установка

Устанавливаем это: npm i css-loader sass-loader node-sass mini-css-extract-plugin -D (если вы не догадались, npm i это тот же npm install

• mini-css-extract-plugin для извлечения CSS в отдельные файлы,
• node-sass для компиляции SCSS в CSS.

3.2 Настройка webpack.config.js

Тут нужно сделать несколько вещей, сначала я скопирую вам готовый webpack.config.js , а потом прокомментирую его по частям.

• На строчке 2 мы подключили наш установленный плагин mini-css-extract-plugin
• Также у нас появились параметры module и plugins
• На строчке 23 указано filename: ‘../style.css’ , что значит – нам не нужно создавать файл в assets, а использовать файл стилей темы.
• На строке 16 я ставлю ?url=false, чтобы webpack не напрягал с путями изображений, так как я их планирую сразу расположить, где мне нужно. А то у вас были бы ошибки типа «Module not found: Error: Can’t resolve ‘./assets/logo.svg»

3.3 Минификация CSS

1. Устанавливаем плагин optimize-css-assets-webpack-plugin npm i optimize-css-assets-webpack-plugin -D
2. Подключаем его в webpack.config.js в начале файла const minify = require(‘optimize-css-assets-webpack-plugin’);
3. Добавляем это:

В итоге файл webpack.config.js будет выглядеть так:

Ничего не произошло при сборке? А вы поменяли в webpack.config.js параметр mode с development на production ? 🙃

Sharing is caring

Понравилось это:

Похожее

Путешествует по миру и рассказывает всем о WordPress лично, у себя в блогах и на курсах в Санкт-Петербурге. Умеет просто объяснять сложные вещи, делает это красиво. Организовывает неплохие WordCamp’s, но совсем не умеет слушать чужие доклады.

Источник

Использование webpack для верстки. Подключение Pug

Использовать webpack для верстке многостраничных сайтов легко.

В текущей сборке уже готово:

• Подключен babel7 — js код автоматический перегонится в старый стандарт и будет работать во всех браузерах
• Весь js код автоматический поджимается
• Подключен SASS (scss) с удобной настройкой под себя
• По желанию можно использовать обычный css
• autoprefixer — префиксы расставятся автоматический, css код будет валидным во всех браузерах
• Все стили будут максимально поджаты с cssnano и mq-packer
• Настроен livereload — авто обновление страницы при любых изменениях в js, css, html
• Авто сплиты для js и css файлов
• Подключен vue.js с удобной интеграцией шаблонов напрямубю в хтмл
• Автоматический или ручной подхват html страниц
• Константы для удобной конфигурации шаблона под себя

Webpack для верстки

Первый вариант — без использования шаблонизатора pug:

Далее следовать простым командам:

Более подробную инструкцию можно найти в README.md — ссылка здесь

Webpack 4 Подключение и настройка pug и pug-loader:

Для устновки pug и pug-loader в терминале:

Далее нужно добавить обработчик для pug файлов:

Обработка pug страниц:

Первое, что нужно сделать это указать, что будем обрабатывать и откуда брать pug файлы:

Далее есть два способа обработки. Первый способ — автоматическое добавление страниц:

Второй способ — ручной (можно легко связывать с первым способом) :

В пример привел страницы индекс и абаут из директории about .

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

Источник

Webpack: основы настройки проекта на JavaScript и Sass

Важно разделять JavaScript и CSS-код на маленькие по объему части. Этим мы упрощаем себе и другим понимание и поддержку проекта. Браузеры, с другой стороны, предпочитают работать с маленьким количеством файлов, пускай длинными и слабо читаемыми. Здесь на помощь приходит Webpack.

Webpack — инструмент веб-разработчика, который соединяет JavaScript- и CSS-файлы в единое целое — файл, который часто называется «bundle» (с англ. «пачка»). В этой статье представлена инструкция по настройке среды для проекта на JavaScript и Sass.

Устанавливаем Node и npm

Webpack построен на Node.js, поэтому для его работы требуется запуск как Node, так и npm (node package manager — менеджер пакетов Node). Порядок действий:

1. Скачиваем и устанавливаем Node.js с официального сайта.
2. Для установки npm открываем командную строку (например, Терминал MacOS) и выполняем команду:

Sudo и ключ -g позволяют установить модуль для всех пользователей через учётную запись администратора, но для этого потребуется ввести пароль.

Выполняем:

При создании файла package.json просто нажимайте «Enter»: настройки по умолчанию приемлемые. Кроме того, при необходимости можно их изменить.

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

Добавляем Webpack

Выполняем следующий код, чтобы добавить Webpack к проекту.

После чего произойдёт 3 вещи:

1. Имя «Webpack» добавится в package.json в качестве devDependency (будет использоваться при разработке, но не в рабочей версии). Для этого указывается ключ -D .
2. Новый каталог node_modules добавится к проекту.
3. Webpack (файлы модуля) появятся в каталоге node_modules .

Добавляем Webpack как скрипт

Добавляем следующий скрипт в package.json :

Теперь запускаем Webpack-версию проекта через npm, выполнив npm run build и npm run start в командной строке.

В документации Webpack глобальную установку не рекомендуют. Она вынуждает разработчика использовать во всех проектах определенную версию Webpack и приводит к краху, если использовать другую версию.

Источник

Webpack: руководство для начинающих

Доброго времени суток, друзья!

Представляю вашему вниманию перевод статьи «Webpack: A gentle introduction» автора Tyler McGinnis.

Перед изучением новой технологии задайте себе два вопроса:

1. Зачем нужен этот инструмент?
2. Какие задачи он выполняет?

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

Зачем нужен вебпак?

Вебпак — это сборщик модулей. Он анализирует модули приложения, создает граф зависимостей, затем собирает модули в правильном порядке в один или более бандл (bundle), на который может ссылаться файл «index.html».

Какие проблемы решает вебпак?

Обычно, при создании приложения на JavaScript, код разделяется на несколько частей (модулей). Затем в файле «index.html» необходимо указать ссылку на каждый скрипт.

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

Как мы скоро узнаем, сбор модулей является лишь одним из аспектов работы вебпака. При необходимости можно заставить вебпак осуществить некоторые преобразования модулей перед их добавлением в бандл. Например, преобразование SASS/LESS в обычный CSS, или современного JavaScript в ES5 для старых браузеров.

Установка вебпака

После инициализации проекта с помощью npm, для работы вебпака нужно установить два пакета — webpack и webpack-cli .

webpack.config.js

После установки указанных пакетов, вебпак нужно настроить. Для этого создается файл webpack.config.js , который экспортирует объект. Этот объект содержит настройки вебпака.

Основной задачей вебпака является анализ модулей, их опциональное преобразование и интеллектуальное объединение в один или более бандл, поэтому вебпаку нужно знать три вещи:

1. Точка входа приложения
2. Преобразования, которые необходимо выполнить
3. Место, в которое следует поместить сформированный бандл

Точка входа

Сколько бы модулей не содержало приложение, всегда имеется единственная точка входа. Этот модуль включает в себя остальные. Обычно, таким файлом является index.js. Это может выглядеть так:

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

Преобразования с помощью лоадеров (loaders)

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

По умолчанию при создании графика зависимостей на основе операторов import / require() вебпак способен обрабатывать только JavaScript и JSON-файлы.

Едва ли в своем приложении вы решитесь ограничиться JS и JSON-файлами, скорее всего, вам также потребуются стили, SVG, изображения и т.д. Вот где нужны лоадеры. Основной задачей лоадеров, как следует из их названия, является предоставление вебпаку возможности работать не только с JS и JSON-файлами.

Первым делом нужно установить лоадер. Поскольку мы хотим загружать SVG, с помощью npm устанавливаем svg-loader.

Далее добавляем его в настройки вебпака. Все лоадеры включаются в массив объектов module.rules :

Информация о лоадере состоит из двух частей. Первая — тип обрабатываемых файлов ( .svg в нашем случае). Вторая — лоадер, используемый для обработки данного типа файлов ( svg-inline-loader в нашем случае).

Теперь мы можем импортировать SVG-файлы. Но что насчет наших CSS-файлов? Для стилей используется css-loader .

Теперь мы можем импортировать как SVG, так и CSS-файлы. Однако для того, чтобы наши стили работали корректно, нужно добавить еще один лоадер. Благодаря css-loader мы можем импортировать CSS-файлы. Но это не означает, что они будут включены в DOM. Мы хотим не только импортировать такие файлы, но и поместить их в тег , чтобы они применялись к элементам DOM. Для этого нужен style-loader .

Обратите внимание, что поскольку для обработки CSS-файлов используется два лоадера, значением свойства use является массив. Также обратите внимание на порядок следования лоадеров, сначала style-loader , затем css-loader . Это важно. Вебпак будет применять их в обратном порядке. Сначала он использует css-loader для импорта ‘./styles.css’ , затем style-loader для внедрения стилей в DOM.

Лоадеры могут использоваться не только для импорта файлов, но и для их преобразования. Самым популярным является преобразование JavaScript следующего поколения в современный JavaScript с помощью Babel. Для этого используется babel-loader .

Существуют лоадеры почти для любого типа файлов.

Точка выхода

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

Весь процесс выглядит примерно так:

1. Вебпак получает точку входа, находящуюся в ./app/index.js
2. Он анализирует операторы import / require и создает граф зависимостей
3. Вебпак начинает собирать бандл, преобразовывая код с помощью соответствующих лоадеров
4. Он собирает бандл и помещает его в dist/index_bundle.js

Плагины (plugins)

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

Давайте рассмотрим пример.

HtmlWebpackPlugin

Основной задачей вебпака является генерация бандла, на который можно сослаться в index.html .

HtmlWebpackPlugin создает index.html в директории с бандлом и автоматически добавляет в него ссылку на бандл.

Мы назвали бандл index_bundle.js и поместили его в dist . HtmlWebpackPlugin создаст новый файл index.html в директории dist и добавит в него ссылку на бандл — . Здорово, правда? Поскольку index.html генерируется HtmlWebpackPlugin , даже если мы изменим точку выхода или название бандла, HtmlWebpackPlugin получит эту информацию и изменить содержимое index.html .

Как нам использовать этот плагин? Как обычно, сначала его нужно установить.

Далее добавляем в настройки вебпака свойство plugins .

Создаем экземпляр HtmlWebpackPlugin в массиве plugins .

EnvironmentPlugin

Если вы используете React, то захотите установить process.env.NODE_ENV в значение production перед разворачиванием (деплоем) приложения. Это позволит React осуществить сборку в режиме продакшна, удалив инструменты разработки, такие как предупреждения. Вебпак позволяет это сделать посредством плагина EnvironmentPlugin . Он является частью вебпака, так что его не нужно устанавливать.

Теперь в любом месте нашего приложения мы можем установить режим продакшна с помощью process.env.NODE_ENV .

HtmlWebpackPlugin и EnvironmentPlugin — это лишь небольшая часть системы плагинов вебпака.

Режим (mode)

В процессе подготовки приложения к продакшну, необходимо выполнить несколько действий. Мы только что рассмотрели одно из них — установку process.env.NODE_ENV в значение production . Другое действие заключается в минификации кода и удалении комментариев для уменьшения размера бандла.

Существуют специальные плагины для решения указанных задачи, но есть более легкий способ. В настройках вебпака можно установить mode в значение development или production в зависимости от среды разработки.

Обратите внимание, что мы удалили EnvironmentPlugin . Дело в том, что после установки mode в значение production вебпак автоматически присваивает process.env.NODE_ENV значение production . Это также минифицирует код и удаляет предупреждения.

Запуск вебпака

На данный момент мы знаем, как работает вебпак и как его настраивать, осталось его запустить.

У нас есть файл package.json , в котором мы можем создать script для запуска webpack .

Теперь при выполнении команды npm run build в терминале будет запущен вебпак, который создаст оптимизированный бандл index_bundle.js и поместит его в dist .

Режимы разработки и продакшна

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

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

Для переключения между режимами необходимо создать два скрипта в package.json .

npm run build будет собирать продакшн-бандл.

npm run start будет запускать сервер для разработки и следить за изменениями файлов.

Если помните, мы установили mode в значение production в настроках вебпака. Однако теперь нам это не нужно. Мы хотим, чтобы переменная среды имела соответствующее значение в зависимости от выполняемой команды. Немного изменим скрипт build в package.json .

Если у вас Windows, то команда будет такой: «SET NODE_ENV=’production’ && webpack» .

Теперь в настроках вебпака мы можем менять значение mode в зависимости от process.env.NODE_ENV .

Для сборки готового бандла для нашего приложения мы просто запускаем npm run build в терминале. В директории dist создаются файлы index.html и index_bunlde.js .

Сервер для разработки

Когда речь идет о разработке приложения принципиально важное значение имеет скорость. Мы не хотим презапускать вебпак и ждать новую сборку при каждом изменении. Вот где нам пригодится пакет webpack-dev-server .

Как следует из названия, это вебпак-сервер для разработки. Вместо создания дирекории dist , он хранит данные в памяти и обрабатывает их на локальном сервере. Более того, он поддерживает живую перезагрузку. Это означает, что при любом изменении webpack-dev-server пересоберет файлы и перезапустит браузер.

Все, что осталось сделать, это добавить скрипт start в package.json .

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

Надеюсь, статья была вам полезной. Благодарю за внимание.

Источник