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.

HtmlWebpackPlugin и его количество скачиваний в неделю по состоянию на 13/12/2022
HtmlWebpackPlugin и его количество скачиваний в неделю по состоянию на 13/12/2022

 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 и всем, что с ними связано.

MiniCssExtractPlugin и его количество скачиваний в неделю по состоянию на 13/12/2022
MiniCssExtractPlugin и его количество скачиваний в неделю по состоянию на 13/12/2022

Вспомним особенность работы 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 — сервер ведения разработки.

Webpack-dev-server и его количество скачиваний в неделю по состоянию на 13/12/2022
Webpack-dev-server и его количество скачиваний в неделю по состоянию на 13/12/2022

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 объединяет несколько конфигурационных файлов в один

Webpack-merge и его количество скачиваний в неделю по состоянию на 13/12/2022
Webpack-merge и его количество скачиваний в неделю по состоянию на 13/12/2022

Webpackbar отвечает за кастомизацию вывода информации в консоль в ходе разработки.

Webpackbar и его количество скачиваний в неделю по состоянию на 13/12/2022
Webpackbar и его количество скачиваний в неделю по состоянию на 13/12/2022

Итоги

Когда вы освоите десяток широко используемых npm-пакетов, вам будет проще разбираться в других.

Большинство пакетов сделаны энтузиастами, поэтому не всегда в их документации есть инструкция по использованию: как, куда и зачем устанавливать. Приведём пример. Возможно, вы слышали про энкрипторы и дескрипторы. Если нет — они отвечают за шифрование данных.

Допустим, у нас есть личный проект, где реализована форма регистрации пользователя (без бэкенда). Куда мы будем отправлять данные?

Первое, что приходит на ум — записывать логин с паролем в LocalStorage. Однако записывать туда данные в незашифрованном виде некорректно. И тут на помощь приходит пакет crypto-js.

При запросе crypto-js npm мы увидим ответ со ссылкой на страницу npm, где написано, что пакет последний раз обновлялся около года назад, имеет около 4–5 миллионов скачиваний в неделю. Неопытный пользователь, заходя на такую страницу, столкнётся с тем, что пакет нужно куда-то скачать и подключить.

Появляется вопрос: куда его ставить, в поле dependencies или devDependencies? Если руководствоваться логикой, то пакеты, которые мы используем только для разработки, должны лежать в поле devDependencies. Если же какие-то части нам нужны после сборки проекта, то такие пакеты улетают в dependencies. У нас как раз второй вариант — данные должны шифроваться на уже задеплоенном проекте.

Прочитали статью?

Нажмите кнопку «Готово», чтобы сохранить прогресс.

Готово

Поделитесь, как вам статья?