Серия небольших корпусов Webpack3.0, я надеюсь, что вы выскажете больше мнений и узнаете вместе:
Webpack3.0 маленький корпус webpack первый опыт
Webpack3.0 небольшой случай, лежащий в яме, обработка css и компиляция ES6
В первых двух статьях мы построили инженерную среду для разработки интерфейса на основе веб-пакета и объяснили основное использование некоторых распространенных плагинов и загрузчиков, включая разделение кода, чтение шаблонов, очистку файлов, компиляцию ES6 и обработку css и т. д. Это article В этой статье я продолжаю исследовать на основе двух предыдущих статей:
- Обработка изображения, включая использование загрузчика файлов, загрузчика URL, загрузчика изображений webpack, разницу между загрузчиком файлов и загрузчиком URL и т. д.
- Сервер запускает webpack-dev-сервер, включая сборку тестового сервера вручную и использование webpack для сборки webpackServer, а также некоторые меры предосторожности.
- оптимизация упаковки веб-пакета, включая сжатие кода, извлечение общедоступного кода и другие конфигурации.
обработка изображения изображения
Webpack обычно использует url-loader, file-loader и image-webpack-loader для обработки изображений. У каждого загрузчика есть свои функциональные обязанности в процессе упаковки. Прежде чем обсуждать их использование, давайте сначала рассмотрим старые правила. Разберемся, что каждый из них сделал.
- file-loader, Скомпилируйте и упакуйте изображения, определенные и загруженные в проект через веб-пакет, и верните закодированный общедоступный URL-адрес.
- url-loader, функция url-loader в основном такая же, как у file-loader. Разница в том, что url-loader может настроить предельное значение, чтобы определить, должно ли изображение возвращать общедоступный URL-адрес, такой как file-loader, или напрямую преобразовывать изображение в кодировке Base64, пропишите по соответствующему пути.
- image-webpack-loader, который используется для сжатия скомпилированного файла и уменьшения размера изображения без потери качества изображения.
file-loader
1. Во-первых, мы создаем новую папку с ресурсами в каталоге src для размещения всех статических ресурсов, В этот каталог мы помещаем две картинкиbg_webpack-sm.jpgа такжеbg_webpack-lg.jpg, размеры 6kb и 12kb соответственно (причина, по которой размещаются две картинки разного размера, заключается в том, чтобы испытать действие параметра limit url-loader).
2. Откройте файл style.less, добавьте класс css контейнера и добавьте div с контейнером имени класса в index.html.
.container{
width:300px;
height: 100px;
background: url('../assets/bg_webpack-lg.jpg')
}
<body>
<div id="app"></div>
<div class="container"></div>
</body>
3. Найдите командную строку в корневом каталоге, установите файл-загрузчик и добавьте правило обработки в файл конфигурации веб-пакета:
cnpm install file-loader --save-dev
...
module: {
rules: [
...
{
test: /\.(png|jpg|gif|svg)$/,
exclude: /node_modules/,
use: [{
loader: 'file-loader',
options: {}
}]
}
]
}
...
Снова выполните команду webpack для компиляции, мы упаковали ресурсы изображений, на которые мы ссылались, в каталоге dist.
конфигурация загрузчика файлов
Теперь файл изображения успешно упакован, но мы обнаружили две проблемы:
- Откройте index.html в папке dist и обнаружите, что картинка не отображается в интерфейсе.
- Упакованный образ создается непосредственно в каталоге dist, а мы хотим, чтобы он генерировался в указанной папке, что явно не соответствует нашим ожиданиям.
Не волнуйтесь, чтобы решить эти две проблемы, нам нужно иметь общее представление о функции некоторых параметров элемента конфигурации файла-загрузчика:
-
name, укажите значение имени файла ресурсов после упаковки и генерации, файл-загрузчик назначает нам некоторые заполнители для настройки имени, мы можем произвольно сопоставить заполнитель, чтобы получить формат имени файла, который мы хотим сгенерировать, по умолчанию это :[хэш].[расш.]
имя описывать [ext] Суффикс имени файла, по умолчанию это суффикс имени исходного ресурса. [name] Имя файла, которое является именем исходного ресурса [path] путь хранения файлов [hash] значение хэша, по умолчанию md5 [N] количество -
publicPath, используемый для указания конфигурации пути в упакованной ссылке css или URL, то естьpulicPath предназначен для пути, а не для самого файла.
-
outputPath, который используется для настройки расположения вывода файла, созданного при упаковке. Он нацелен на место, где хранится файл, и не имеет ничего общего со ссылкой на путь в коде.
-
useRelativePath， 配置打包生成后的路径是否为相对位置，默认情况下是false。 должны знать о том,После включения useRelativePath настройка outputPath будет основываться на папке с ресурсами в каталоге src, и установка других имен не вступит в силу..
-
emitFile, укажите, нужно ли публиковать упакованные файлы ресурсов, значение по умолчанию — true.
Из этих элементов конфигурации мы можем примерно найти причины двух вышеуказанных проблем:
- 1. Неверное место генерации образа, потому что мы не указали outputPath, и значение вывода (output) было прочитано по умолчанию;
- 2. Откройте в браузере, но изображение не отображается, потому что значение publicPath не установлено, поэтому фоновый URL-адрес сгенерированного css автоматически по умолчанию будет на том же уровне, что и файл css, что приведет к неправильному URL-адресу, поэтому найдите Нет ресурсов изображения.
Поэтому для этих двух задач настраиваем конфигурационный файл:
...
module: {
rules: [
...
{
test: /\.(png|jpg|gif|svg)$/,
exclude: /node_modules/,
use: [{
loader: 'file-loader',
options: {
name: '[hash].[ext]',
outputPath: '/assets/',//定义图片输出存放的文件夹位置
useRelativePath: true,//设置路径为相对位置
}
}]
}
]
}
...
В элементе конфигурации мы определяем имя вывода файла, которое будет называться после хеш-значения, и указываем, что файл выводится в папку ресурсов под dist, затем открываем путь как относительный путь, снова выполняем компиляцию веб-пакета и найти, что файл был создан в соответствии с настройками.Перейдите в каталог активов.
Откройте index.html под dist, изображение успешно загружено
Конечно, при установке опции file-loader, так как paublicPath будет считывать значение publicPath в экспорте webpack, между ними есть связь. настройки в середине должны быть изменены соответствующим образом, и этот момент следует хорошо усвоить.
url-loader
Как мы уже говорили ранее, url-loader является инкапсуляцией file-loader, поэтому методы использования url-loader и file-loader в основном одинаковы, здесь мы обсудим их различие, то есть параметр limit.
1. Сначала мы устанавливаем url-loader, заменяем предыдущий file-loader на url-loader и добавляем элемент div с именем класса container-sm на страницу index.html.
cnpm install url-loader --save-dev
// webpack.config.js
...
module: {
rules: [
...
{
test: /\.(png|jpg|gif|svg)$/i,
exclude: /node_modules/,
use: [{
loader: 'url-loader',
options: {
limit: 10240,
outputPath: 'assets/',
useRelativePath: true
}
}]
}
]
}
...
В пункте конфигурации указываем, что в файл будет загружаться изображение больше 10кб, а файл меньше 10кб будет напрямую преобразован в кодировку base64 и записан сразу в css, так что результат двух только что положенных нами изображений in должен быть больший с изображением Ресурс загружается, а меньший напрямую кодируется в base64 и записывается в файл css. Окончательный эффект выглядит следующим образом:
Можно обнаружить, что результат такой же, как мы ожидали, что указывает на то, что загрузчик URL-адресов вступил в силу. url-loader очень помогает нам при работе с маленькими изображениями, он может эффективно сократить количество посещений сервера и сократить время посещения, особенно для некоторых иконок.
При использовании url-loader нам нужно взвесить предельное значение; кодировка base64 может уменьшить количество посещений браузера, но ее недостаток в том, что кодировка очень длинная, что легко может привести к большему размеру кода. Метод path может уменьшить объем кода, а также браузер будет кешировать файл при многократном обращении к нему, но ведь это увеличит количество обращений к ресурсам сервера. Следовательно, как установить размер лимита, необходимо определить в зависимости от ситуации в проекте.
сжатие изображений image-webpack-loader
Поскольку url-loader будет увеличивать размер файла при обработке файла, например, при кодировании файла base64, размер файла будет больше, чем у исходной версии, поэтому появился image-webpack-loader. Функция заключается в том, чтобы сначала сжать статические ресурсы перед обработкой загрузчика URL, а затем решить, следует ли использовать кодировку base64 для обрабатываемых ресурсов изображения.
1. Сначала устанавливаем image-webpack-loader, а потом модифицируем в конфигурации webpack:
cnpm install image-webpack-loader --save-dev
// webpack.config.js
...
module: {
rules: [
...
{
test: /\.(png|jpg|gif|svg)$/i,
exclude: /node_modules/,
use: [{
loader: 'url-loader',
options: {
limit: 10240,
outputPath: 'assets/',
useRelativePath: true
}
}, {
loader: 'image-webpack-loader',//新增image-webpack-loader
options: {
mozjpeg: {//设置对jpg格式的图片压缩的程度设置
progressive: true,
quality: 65
},
}
}]
}
]
}
...
В элементе конфигурации мы сжимаем изображение и устанавливаем изображение типа jpg для сжатия до значения качества 65. Наконец, запустите команду webpack и обнаружите, что оба изображения сжаты до изображений размером 4,75 КБ. В css два изображения All уже отображаются в кодировке base64.
image-webpack-loader имеет разные параметры конфигурации обработки для разных типов изображений, и разработчики могут настраивать степень сжатия для разных разработчиков изображений.
- gifsicle — сжатый формат изображения gif.
- mozjpeg — сжатый формат изображения JPEG
- optipng — сжатый формат изображения PNG
- pngquant — Сжимает формат изображения PNG
- webp — сжимает изображения PNG и JPEG в формат webp.
- svgo — сжатый формат изображения SVG.
Параметры запуска сервера
Пока в нашем маленьком кейсе разобрались с общими базовыми загрузчиками, но мы обнаружили некоторые проблемы, такие как необходимость перекомпилировать вебпак после каждого изменения кода, а наши файлы так и остаются в файловой системе.Метод открывается в браузере .Похоже, это не та поза кодирования, которую предоставляет нам webpack.Поэтому далее мы рассмотрим ряд вопросов, например, как заставить наш проект работать на сервере.
Сделай промежуточный сервер своими руками
Поскольку мы указали, что окончательные упакованные файлы веб-пакета находятся в каталоге dist, теперь нам просто нужно запустить файлы в dist на стороне сервера.Это кажется возможным, поэтому я попробую сначала.
1. В корневом каталоге создайте новый файл server.js и установите экспресс
cnpm install express --save-dev
2. В server.js мы используем экспресс для написания простого сервера:
//server.js
var path = require('path');
var express = require('express');
var app = express();
var port = process.env.port || 3000;
app.use(express.static(path.join(__dirname, 'dist')));//设置可访问的静态资源目录
app.get('/', function(req, res, next) {
req.url = 'index.html';
next()
})
app.listen(port, function() {
console.log(`server is running at ${port}`)
});
3. Откройте package.json и добавьте следующую команду в элемент конфигурации скрипта:
//package.json
...
"scripts": {
"server": "node server.js",//设置用node运行server.js
"build": "webpack"//设置webpack编译命令
}
...
Итак, мы можем запустить проект через cnpm в консоли:
cnpm run build /*执行webpack打包命令*/
cnpm run server /*让编译后的文件通过服务器加载*/
После выполнения приведенной выше команды введите в браузере: localhost:3000, чтобы получить доступ к окончательному упакованному файлу.Однако нужное нам горячее обновление по-прежнему недоступно, и его по-прежнему необходимо каждый раз упаковывать.Наша проблема не решена ( черное лицо подавленное).
webpack-dev-server
На самом деле, чтобы решить эту проблему в разработке компиляции в реальном времени, WebPack уже предоставляет нам простой способ.
webpack-dev-server — это небольшой экспресс-сервер nodejs, который поддерживает два режима автоматического обновления страницы, и оба обеспечивают горячие обновления.Наша практика использует встроенный режим в качестве примера.
- режим iframe, страница помещается в iframe и перезагружается, когда что-то меняется
- Встроенный режим, добавьте клиентскую запись webpack-dev-sever в бандл (bundle)
Преимущество горячего обновления в том, что заменяется только обновленная часть без необходимости перезагрузки страницы.
1. Установите webpack-dev-сервер
cnpm install webpack-dev-server --save-dev
2. После завершения установки мы открываем файл package.json и добавляем в элемент конфигурации скрипта следующее:
//package.json
...
"scripts": {
"server": "node server.js",//设置用node运行server.js
"build": "webpack",//设置webpack编译命令
"dev": "webpack-dev-server"
}
...
Таким образом, мы можем запустить проект, если введем «cnpm run dev» в командной строке.
3. При работе с webpack-dev-server порт по умолчанию — 8080. Поэтому после запуска webpack-dev-server мы можем получить доступ к проекту, выполнив в браузере localhost:8080. В настоящее время, поскольку проект находится в среда разработки, файл только хранится в памяти и толком не запакован.Поэтому папка dist не будет сгенерирована в проекте.Из-за этого, когда мы будем динамически менять код, webpack будет автоматически обновлять интерфейс.
webpack также предоставляет нам узел для настройки webpack-dev-server в элементе конфигурации, то есть элемент конфигурации devServer, в этом элементе конфигурации мы можем изменить номер порта для запуска, режим загрузки (iframe или inline), д., но нужно знать,webpack3.0 был обновлен в горячем режиме по умолчанию.Если атрибут hot снова установлен в devServer, горячее обновление завершится ошибкой.
...
entry: path.resolve(__dirname, './src/main.js'),
output: {
path: path.resolve(__dirname, './dist'),
filename: 'js/[name]-[chunkhash].js'
},
devServer: {
// hot: true, 不要设置hot热更新属性，设定后反而会失效
port: 3000,
inline: true
},
...
оптимизация упаковки веб-пакета
Оптимизация веб-пакета — очень техническая тема, и предполагается, что она будет относительно длинной с точки зрения расширения.В этом разделе мы перечислим несколько элементов для нашей текущей структуры проекта.
Сжатие кода UglifyJsPlugin
UglifyJsPlugin — это оптимизатор сжатия кода, предоставляемый webpack по умолчанию. Когда этот плагин используется в элементе конфигурации, упакованный js-файл будет подвергнут таким методам сжатия, как сжатие кода и удаление комментариев. Это уменьшит размер упакованного js-файла, когда проект построен Объем ст.
...
plugins: [
//启用js压缩
new webpack.optimize.UglifyJsPlugin({
compress: {
warnings: false,
drop_console: false,
}
}),
new htmlWebpackPlugin({
template: 'index.html',
filename: 'index.html'
}),
new cleanWebpackPlugin(
['dist'], {
verbose: false,
dry: false,
root: __dirname
}
)
]
...
Уменьшить область включения && исключить
В настройках загрузчика webpack каждый загрузчик позволяет указать файлы обработки, включая или не включая файлы в какую папку, что значительно сократит объем сканирования и время упаковки. На самом деле в нашем проекте мы установили параметр exclude, чтобы исключить загрузчик из проверки файлов в node_modules.
{
test: /\.js$/,
use: [{ loader: "babel-loader" }],
exclude: /node_modules/,
include: /src/
}
Извлечение общего кода CommonsChunkPlugin
Подключаемый модуль CommonsChunkPlugin, предоставляемый webpack по умолчанию, может извлекать общие модули в коде, такие как часто используемые сторонние подключаемые модули, такие как jquery и moment.Если он упакован в каждый ссылочный упакованный файл js, конечный объем проекта будет Multiplied, используя CommonsChunkPlugin, эти общие части могут быть извлечены, эффективно уменьшая размер проекта.
Установите для cacheDirectory Babel значение true
Компиляция Babel — это трудоемкий процесс.Для настроек обработки babel нам нужно не только установить include && exclude, чтобы найти скомпилированные файлы как можно точнее, но и полностью использовать кеш для дальнейшего повышения скорости. cacheDirectory в true, да Хороший способ оптимизации.
{
test: /\.js$/,
use: [{ loader: "babel-loader" ,cacheDirectory: true}],
exclude: /node_modules/,
include: /src/
}
наконец
В этом разделе мы суммируем обработку статических ресурсов, загрузку сервера и оптимизацию упаковки веб-пакетов из веб-пакета, На самом деле, многое еще не завершено, и многие места не были подробно объяснены, но путешествие в тысячу миль начинается с одного шага. , шаг за шагом Приходите, я верю, что вы получите то, что вы хотите в конце концов.
Тем не менее, не забудьте сказать, я надеюсь, что вы станете квалифицированным мастером интерфейса как можно скорее, давай!