5.2. Необходимые в разработке плагины
Поговорим о том, какие плагины должны быть в любом проекте, где есть файлы HTML, CSS и JS.
Начнём с двух правил:
- любой плагин и обработчик подключается с использованием ключевого слова
require; - плагины подключаются в поле
pluginsфайла webpack.config.js путём создания нового инстанса класса с использованиемnew.
| Плагины | Краткое описание |
|---|---|
|
HtmlWebpackPlugin |
Один из важнейших плагинов, отвечает за работу с файлами HTML |
|
MiniCssExtractPlugin |
Отвечает за обработку стилей и создание отдельного файла с ними после билда проекта |
|
webpack-dev-server |
Сервер для разработки |
Примеры использования
Напоминаем, все пакеты (плагины) ставятся с использованием команды:
npm i <имя>
Если плагин нужен только для ведения разработки, используется команда:
npm i <имя пакета> -D
HtmlWebpackPlugin
HtmlWebpackPlugin — уже знакомый нам плагин для работы с файлами формата .html.
new HtmlWebpackPlugin({
inject: 'head',
template: `./index.html`,
filename: `./index..html`,
chunks: 'index.js',
minify: {
favicon: 'favicon.ico'
collapseWhitespace: true,
removeComments: true,
useShortDoctype: true
},
}),
inject — принимает только строковые значения head или body, отвечающие за то, куда после сборки будет подключён JS-тег с указанием пути к исполняемому файлу (в автоматическом режиме).
template и filename — отвечают за то, откуда брать файл (в случае с template — шаблон) и как назвать файл после сборки (в случае с filename).
chunks — отвечает за указание конкретного JS-файла, привязанного к определённой HTML-странице.
minify — встроенная оптимизация, содержащая некоторые поля, является объектом.
favicon — конкретному HTML-файлу можно указывать иконку прямо из конфига.
collapseWhitespace — после сборки убирает всё пустое пространство между символами.
removeComments — удаляет все комментарии из кода.
useShortDoctype — принимает только булевые значения true и false, отвечает за укорачивание тега doctype.
MiniCssExtractPlugin
MiniCssExtractPlugin — плагин для работы со стилями CSS и всем, что с ними связано.
Вспомним особенность работы webpack: здесь стили подключаются (импортируются) непосредственно в тот JS-файл, который указан в качестве входной точки. То есть стили инлайнятся в сам код, и из-за них увеличивается общий размер бандла. Так вот, плагин MiniCssExtractPlugin помогает этого избежать.
MiniCssExtractPlugin извлекает из JS-файла все стили и создаёт под них отдельный файл:
module.exports = {
plugins: [
new MiniCssExtractPlugin({
filename: 'css/[name]_[contenthash].css',
})
]
}
filename — отвечает за то, куда будет положен файл со стилями и какое он получит имя.
Этот плагин также выступает в качества обработчика:
module.exports = {
// остальной конфиг
rules: [
{
test: /\.(s[ac]|c)ss$/i, // обрабатываем все возможные форматы со стилями
use: [MiniCssExtractPlugin.loader, 'style-loader', 'css-loader', 'postcss-loader'], // обработчики
}
]
}
Обработчики читаются справа налево. То есть MiniCssExtractPlugin отработает в самом конце. Это как раз и создаст нам отдельный файл под все стили, предварительно преобразуя всё то, на чём мы писали: SCSS, Sass или LESS.
Webpack-dev-server
Webpack-dev-server — сервер ведения разработки.
module.exports = {
devServer: {
static: {
directory: path.join(__dirname, './public'),
},
client: {
overlay: {
errors: true,
warnings: false,
},
progress: true,
},
open: true,
compress: true,
port: 3200,
hot: false,
}
}
Webpack-dev-server заменяет Live Server (VS Code) и Live Edit (WebStorm).
static и directory — позволяют настроить параметры для обработки статических файлов из директории (по умолчанию «public» каталог).
client — объект со своими полями. Позволяет скрывать или показывать окно вывода ошибок и подробную информацию о времени компиляции кода, ведь «под капотом» dev-server хранит собранный проект в оперативной памяти компьютера.
errors и warnings — ошибки и предупреждения, progress — детализация времени сборки.
open — принимает только булевые значения. Открывает страницу проекта в новом окне браузера по умолчанию.
compress — принимает булевые значения. Отвечает за оптимизацию во время разработки, сжатие GZIP.
Дополнительные пакеты
Для удобства мы будем использовать пакеты webpack-merge и webpackbar.
Webpack-merge объединяет несколько конфигурационных файлов в один
Webpackbar отвечает за кастомизацию вывода информации в консоль в ходе разработки.
Итоги
Когда вы освоите десяток широко используемых npm-пакетов, вам будет проще разбираться в других.
Большинство пакетов сделаны энтузиастами, поэтому не всегда в их документации есть инструкция по использованию: как, куда и зачем устанавливать. Приведём пример. Возможно, вы слышали про энкрипторы и дескрипторы. Если нет — они отвечают за шифрование данных.
Допустим, у нас есть личный проект, где реализована форма регистрации пользователя (без бэкенда). Куда мы будем отправлять данные?
Первое, что приходит на ум — записывать логин с паролем в LocalStorage. Однако записывать туда данные в незашифрованном виде некорректно. И тут на помощь приходит пакет crypto-js.
При запросе crypto-js npm мы увидим ответ со ссылкой на страницу npm, где написано, что пакет последний раз обновлялся около года назад, имеет около 4–5 миллионов скачиваний в неделю. Неопытный пользователь, заходя на такую страницу, столкнётся с тем, что пакет нужно куда-то скачать и подключить.
Появляется вопрос: куда его ставить, в поле dependencies или devDependencies? Если руководствоваться логикой, то пакеты, которые мы используем только для разработки, должны лежать в поле devDependencies. Если же какие-то части нам нужны после сборки проекта, то такие пакеты улетают в dependencies. У нас как раз второй вариант — данные должны шифроваться на уже задеплоенном проекте.