1. Проблемы с упаковкой webpack
Порядок упаковки webpack:
var path = require('path');
module.exports = {
entry: {
one: "./src/one.js",
two: "./src/two.js"
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: "[name].js"
}
};
1. Найдите файл записи
2. По входному файлу узнать файл js/css с зависимостями
3. Наконец, упакуйте все css/js в пакет js
Итак, упаковка завершена, и весь мир упакован, поэтому возникает проблема:
Продукт говорит: Цвет кнопки неправильный, измените его на #ccc для меня.
Технология: Хорошо, давайте изменим это.
Затем происходит следующий процесс:
1, найденная запись -> js -> компонент -> button.css для изменения значения цвета
2, выполнить пакет WebPack
На данный момент проблема выявляется:
1. Очевидно, было изменено только значение цвета, но его необходимо переупаковать со входа.
2. Бизнес-код, очевидно, не изменился, но он также был замешан
3. Все сгенерированные js должны быть отправлены в онлайн, чтобы покрыть бизнес-js, которые не были проблемой при удалении онлайн, что чисто для увеличения риска.
Во-вторых, подумайте о решениях
Первое, что приходит на ум, это то, что, поскольку модифицируется только один файл, можно ли его переупаковать?
1. Упаковать обновленные файлы отдельно?
Этот план был быстро опровергнут.
потому что:
1. Файлы, запакованные из записи, прошли зависимости, а старая версия button.less была занесена в итоговый выходной js-файл.
2. Пакет button.less сам по себе выводит независимый button.js.Этот файл нужно вручную импортировать в html.Как только таких файлов будет сделано слишком много, их вообще нельзя будет поддерживать.
После неоднократных размышлений идея упаковки каждого файла по отдельности не соответствует первоначальному дизайнерскому замыслу веб-пакета, и процесс упаковки от входа не может быть изменен.
Застрял на этом вопросе в течение очень долгого времени ..... в течение длительного времени
2. Можно ли упаковать определенную запись через зависимости?
Поскольку сценарий, с которым я сталкиваюсь, представляет собой многостраничное приложение, существует несколько записей, поэтому в этом случае я могу найти запись, которую необходимо обновить, через зависимости?
Этот план тоже долго рассматривался, но позже был отвергнут.
потому что:
1. Плагина подходящего для вывода зависимостей модулей в webpack нет, и поиски безрезультатны.
2. Через индикаторы анализа статистики вебпака зависимости можно выводить, но объем данных слишком велик.Если фильтрация не добавлена, то текущий проект выдает 12W строк json-информации, и требуется усилие для обработки этой информации, чтобы получить отношение.
3. Если на компонент ссылаются несколько записей, вам нужно найти точку входа каждой ссылки, а затем переупаковать каждую затронутую запись.
Вышеупомянутое, особенно третий пункт, совершенно не соответствует цели инкрементального релиза: при изменении компонента кнопки необходимо переупаковывать 20 или 30 записей, что вообще не имеет смысла инкрементальный релиз.
Долго мучался с этой проблемой... давно
Три, разумное решение
Пройдя первые два вопроса, я обнаружил, что направление мышления совершенно неверное, я всегда хочу изменить метод упаковки webpack, что как раз противоречит его концепции.
Поскольку я не могу изменить метод упаковки webpack, могу ли я изменить вывод webpack?
Фактически, webpack предоставляет множество мощных плагинов для функций кэширования, таких как:
-
CommonsChunkPlugin можно использовать для извлечения общего кода js при упаковке.
-
ExtractTextPlugin можно использовать для извлечения css из js и вывода его в отдельный файл.
Используя эти два плагина, мы смогли разделить точность нашей упаковки, упаковав часть общей ссылки в один файл.
Если часть публичной ссылки станет отдельным файлом, добавить хэш для кеширования, а при повторном изменении просто обновить хэш, чтобы мы не могли определить, какой файл был изменен?
В таком случае давайте рассмотрим шаг за шагом:
1. Сначала используйте CommonsChunkPlugin для извлечения общедоступных js
Теперь мы создаем файл тестовой записи:
src/one.js:
import jquery from 'jquery';
console.log('one');
src/two.js:
import jquery from 'jquery';
console.log('two');
webpack.config.js
var path = require('path');
module.exports = {
entry: {
one: "./src/one.js",
two: "./src/two.js"
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: "[name].js"
}
};
выполнить веб-пакет
Выводятся два файла, каждый из которых имеет размер 271 КБ. Это связано с тем, что и one.js, и two.js ссылаются на jquery, а jquery упакован дважды и упакован в два файла соответственно.
Это явно не очень дружелюбно.Файлы типа jquery явно не меняются в обычное время.Лучше их кешировать.Изменить webpack.config.js
var webpack = require("webpack");
var path = require('path');
module.exports = {
entry: {
one: "./src/one.js",
two: "./src/two.js"
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: "[name].js"
},
plugins:[
new webpack.optimize.CommonsChunkPlugin({
name: "common",
}),
]
};
Теперь мы добавили плагин CommonsChunkPlugin, его роль заключается в извлечении общих js и повторном выполнении веб-пакета.
Вы можете видеть, что размер one.js и two.js меньше 1 КБ, а размер common — 274 КБ.Вы можете видеть, что jquery был упакован в common.js
2. Добавьте хэш в файл
var webpack = require("webpack");
var path = require('path');
module.exports = {
entry: {
one: "./src/one.js",
two: "./src/two.js"
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: "[name].[hash:6].js"
},
plugins:[
new webpack.optimize.CommonsChunkPlugin({
name: "common",
}),
]
};
Выходное содержимое вывода изменено выше[name].[hash].js
Теперь запустите веб-пакет:
Вы можете видеть, что у трех упакованных файлов есть хеш, но вам нужна идея.На данный момент хэш каждого файла одинаков.
Снова запустите веб-пакет:
Видно, что результаты двух выходных данных сборки совпадают, что хорошо, потому что файл не модифицируется, и, естественно, хеш не должен измениться.
Итак, затем измените файл: one.js
import jquery from 'jquery';
console.log('修改one');
Трагедия, все файлы были изменены по хешу, проверьте вывод:
Бывает так, что модифицируется только один файл, но модифицируется хеш всех файлов, проблема очень серьезная и явно не то, что нам нужно.
3. Используйте чанкхэш вместо хеша
webpack в отношении кеширования предоставляет несколько способов добавить хеш, где есть chunkhash
Короче говоря, chunkhash — это добавление хэша в соответствии с содержимым модуля.В этом случае, пока файл не изменится, новый хеш не будет сгенерирован.
var webpack = require("webpack");
var path = require('path');
module.exports = {
entry: {
one: "./src/one.js",
two: "./src/two.js"
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: "[name].[chunkhash:8].js"
},
plugins:[
new webpack.optimize.CommonsChunkPlugin({
name: "common",
}),
]
};
Как показано выше, изменитеfilename:[name].[chunkhash:8]/js
выполнить веб-пакет
Вы можете видеть, что хэш, сгенерированный на этот раз, равен 4897....
Но хеш каждого выходного файла не 4897....
Отлично, давайте снова запустим webpack:
Видно, что хэш не изменился между двумя выходами.
Теперь измените one.js и запустите webpack.
import jquery from 'jquery';
console.log('使用chunkhash后修改one');
Видно, что хэш two.js не изменился, хэш one.js изменился, но хэш common.js тоже изменился...
4. Извлечь манифест
После извлечения кода с помощью CommonsChunkPlugin общий код был извлечен, но между ними должно быть отношение сопоставления, например
Причина, по которой хэш commonjs изменится, заключается в том, что изменение one.js генерирует новый хэш, а jquery имеет отношение сопоставления с one.js,映射关系会更新
, что означает, что common.js подтягивает jquery из нового.js
а такжеmanifest
Его можно просто понимать как набор взаимосвязей сопоставления модулей, и этот манифест будет упакован вместе с этими отдельными кодами! ! !
Итак, теперь отдельный манифест
var webpack = require("webpack");
var path = require('path');
module.exports = {
entry: {
one: "./src/one.js",
two: "./src/two.js"
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: "[name].[chunkhash:8].js"
},
plugins:[
new webpack.optimize.CommonsChunkPlugin({
name: "common",
}),
new webpack.optimize.CommonsChunkPlugin({
name: 'manifest' // 用于提取manifest
})
]
};
Это в основном для использования функции CommonsChunkPlugin для извлечения общедоступного кода через имя по умолчанию, потому что webpack упаковывает модуль по умолчанию, который является манифестом, поэтому мы можем использовать это для достижения
Теперь выполняем вебпак:
Как видите, выводится еще один manifest.js
Затем измените one.js
import jquery from 'jquery';
console.log('分离manifest后修改one');
Видно, что теперь изменился только хэш one.js и manifest.js, а common.js успешно закэширован
Используйте инструмент сравнения кода, чтобы сравнить разницу между двумя манифестами, и вы увидите, что сопоставленный chunkid действительно изменился.
5. Используйте плагин webpack-md5-hash
Мы выводим manifest.js ранее, но этот manifest.js тоже нужно обрабатывать отдельно, поэтому можно использовать другой плагин webpack, webpack-md5-hash
var webpack = require("webpack");
var WebpackMd5Hash = require('webpack-md5-hash');
var path = require('path');
module.exports = {
entry: {
one: "./src/one.js",
two: "./src/two.js"
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: "[name].[chunkhash:8].js"
},
plugins:[
new WebpackMd5Hash(),
new webpack.optimize.CommonsChunkPlugin({
name: "common",
}),
]
};
Выполнить пакет:
Нет вывода манифеста, измените one.js
import jquery from 'jquery';
console.log('使用WebpackMd5Hash修改one');
Упакуйте снова:
На этот раз изменился только хеш one.js
Хотя webpack-md5-hash решил нашу проблему, он также превратил отношения упакованных модулей в черный ящик.Существуют определенные неизвестные риски, и нам нужно тщательно оценить, есть ли проблема.
6. Упакуйте библиотеку со сверхнизкой частотой модификации
Общий код был извлечен раньше, но проблемы все еще есть.Если lodash нужно будет ввести в это время, изменится ли общий хэш?
Изменить one.js
import jquery from 'jquery';
import lodash from 'lodash';
console.log('引入lodash修改one');
Изменить два.js
import jquery from 'jquery';
import lodash from 'lodash';
console.log('引入lodash修改two');
В этот раз изменился хэш всех файлов, не только это, но и что более важно, увеличился размер общего
Это значит, что lodash тоже входит в общий, но это само по себе неправильное поведение, lodash и jquery, как правило, вообще его не модифицируют, в таком случае его нужно оптимизировать и упаковывать отдельно
Теперь измените webapack.config.js.
var webpack = require("webpack");
var WebpackMd5Hash = require('webpack-md5-hash');
var path = require('path');
module.exports = {
entry: {
two: "./src/two.js",
one: "./src/one.js",
common:['jquery','lodash']
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: "[name].[chunkhash:8].js"
},
plugins:[
new WebpackMd5Hash(),
new webpack.optimize.CommonsChunkPlugin({
name: "common",
}),
]
};
В этот раз на вход добавляется common, а common указывает только на jquery и lodash, на этот раз выполняем упаковку
На данный момент явных изменений в содержимом вывода нет, файлов тоже три, размер точно такой же, проблем с хешированием нет.
Как видите, размер common равен 817k.
Что делать, если в это время используются другие пакеты? Например, введение реакции
Изменить one.js
import jquery from 'jquery';
import lodash from 'lodash';
import react from 'react';
console.log('引入react修改one');
Изменить два.js
import jquery from 'jquery';
import lodash from 'lodash';
import react from 'react';
console.log('引入react修改one');
выполнить веб-пакет
Здесь возникает проблема, размер общего увеличился, очевидно, что реакция упакована, но что, если мы просто хотим постоянно кэшировать jquery и lodash в это время?
Изменить webpack.config.js
var webpack = require("webpack");
var WebpackMd5Hash = require('webpack-md5-hash');
var path = require('path');
module.exports = {
entry: {
two: "./src/two.js",
one: "./src/one.js",
common:['jquery','lodash']
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: "[name].[chunkhash:8].js"
},
plugins:[
new WebpackMd5Hash(),
new webpack.optimize.CommonsChunkPlugin({
name: 'common',
minChunks:Infinity
})
]
};
На этот раз добавьте предложениеminChunks:Infinity
Атрибут minChunks может быть установлен равным 2, что означает, что извлекаются модули со счетчиком ссылок, равным 2, иInfinity
Это означает бесконечность, а бесконечность означает, что не будет лишнего, что можно было бы упаковать.
Теперь выполните упаковку веб-пакета
Видно, что common восстановил сейчас 816k.React, конечно, не был извлечен.Он все еще находится в двух файлах.Далее продолжаем извлекать react.
var webpack = require("webpack");
var WebpackMd5Hash = require('webpack-md5-hash');
var path = require('path');
module.exports = {
entry: {
two: "./src/two.js",
one: "./src/one.js",
common:['jquery','lodash'],
react:['react','react-redux']
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: "[name].[chunkhash:8].js"
},
plugins:[
new webpack.optimize.CommonsChunkPlugin({
name: ['react','common'], // 用于提取manifest
minChunks:Infinity
}),
new WebpackMd5Hash(),
]
};
С помощью приведенной выше конструкции мы упаковали и сохранили хэш библиотеки классов, который не будет изменен.
7. Введите фиксированный идентификатор модуля HashedModuleIdsPlugin.
Выглядит идеально спереди, но если мы сейчас изменим порядок входов
entry: {
react:['react','react-redux'],
two: "./src/two.js",
one: "./src/one.js",
common:['jquery','lodash'],
}
Видно, что хэш общей и общей библиотек реакции снова изменился, это связано с тем, что идентификатор модуля увеличивается в соответствии с порядком синтаксического анализа веб-пакета.Если порядок синтаксического анализа изменится, идентификатор модуля также изменится соответственно.
Поэтому нужен HashedModuleIdsPlugin, который генерирует ID модуля по относительному пути модуля.Если модуль не изменится, ID модуля не изменится.
var webpack = require("webpack");
var WebpackMd5Hash = require('webpack-md5-hash');
var path = require('path');
module.exports = {
entry: {
common:['jquery','lodash'],
react:['react','react-redux'],
two: "./src/two.js",
one: "./src/one.js",
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: "[name].[chunkhash:8].js"
},
plugins:[
new webpack.optimize.CommonsChunkPlugin({
name: ['react','common'], // 用于提取manifest
minChunks:Infinity
}),
new webpack.HashedModuleIdsPlugin(),
new WebpackMd5Hash(),
]
};
Теперь после упаковки идентификация модуля уже не id, а четырехзначный код, чтобы можно было зафиксировать ip адрес.
8. Используйте extract-text-webpack-plugin для извлечения файлов css
Создайте one.css в src:
body{
color:blue;
}
two.css
h1{
font-size:24px;
}
Измените one.js и two.js, чтобы импортировать css
import jquery from 'jquery';
import lodash from 'lodash';
import react from 'react';
import './one.css'
console.log('引入css修改one');
Изменить webpack.config.js
var webpack = require("webpack");
var WebpackMd5Hash = require('webpack-md5-hash');
var path = require('path');
var ExtractTextPlugin = require("extract-text-webpack-plugin");
module.exports = {
entry: {
common: ['jquery', 'lodash'],
react: ['react', 'react-redux'],
two: "./src/two.js",
one: "./src/one.js",
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: "[name].[chunkhash:8].js"
},
module: {
rules: [
{
test: /\.css$/,
use: ExtractTextPlugin.extract({
fallback: "style-loader",
use: "css-loader"
})
}
]
},
plugins: [
new webpack.optimize.CommonsChunkPlugin({
name: ['react', 'common'], // 用于提取manifest
minChunks: Infinity
}),
new ExtractTextPlugin("[name].[chunkhash:8].css"),
new webpack.HashedModuleIdsPlugin(),
new WebpackMd5Hash()
]
};
Выполнить веб-пакет:
Видно, что js и css успешно выводятся, но есть небольшое сомнение, что хэш one.css и one.js один и тот же.В таком случае, что если мы изменим one.css?
Измените one.css и снова упакуйте его:
Обнаружено, что хэш css не изменился.
Затем измените one.js и снова упакуйте его:
На этот раз хэши one.js и one.css изменились одновременно.
9. Используйте contenthash для извлечения хэша фиксированного css
- When using the ExtractTextWebpackPlugin, use [contenthash] to obtain a hash of the extracted file (neither [hash] nor [chunkhash] work).
Выходной документ веб-пакета написан. После извлечения css используйте хэш содержимого, чтобы добавить хэш
var webpack = require("webpack");
var WebpackMd5Hash = require('webpack-md5-hash');
var path = require('path');
var ExtractTextPlugin = require("extract-text-webpack-plugin");
module.exports = {
entry: {
common: ['jquery', 'lodash'],
react: ['react', 'react-redux'],
two: "./src/two.js",
one: "./src/one.js",
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: "[name].[chunkhash:8].js"
},
module: {
rules: [
{
test: /\.css$/,
use: ExtractTextPlugin.extract({
fallback: "style-loader",
use: "css-loader"
})
}
]
},
plugins: [
new webpack.optimize.CommonsChunkPlugin({
name: ['react', 'common'], // 用于提取manifest
minChunks: Infinity
}),
new ExtractTextPlugin("[name].[contenthash:8].css"),
new webpack.HashedModuleIdsPlugin(),
new WebpackMd5Hash()
]
};
На этот раз изменяется только выходной хеш.Conenthash представляет хеш-значение содержимого текстового файла, то есть только хеш-значение файла стиля.
Выполнить веб-пакет:
Хэш one.js и one.css изменился
Затем измените one.css
body{
color:white;
}
Снова запустите веб-пакет:
Пока что только One.css изменился, и приготовления здесь в основном.
В-четвертых, оптимизировать многостраничное время упаковки и стабилизируйте хеш
1, ограничить вход
Поскольку это многостраничное приложение, оно упаковывается путем сканирования файла записи.Правило заключается в том, что файл js является файлом записи, а ресурс, на который ссылается jsx, не распознается как запись.
Путем анализа плагина BundleAnalyzerPlugin было установлено, что некоторые компоненты были запакованы как входы.После разборки они были переупакованы, и время упаковки сократилось на 2/3.Конечно это заливка предыдущей ямы .
Время упаковки продукции74578ms
В это время время упаковки сжатого и несжатого также в 3 раза:
Время разработки и упаковки составляет24780ms
Хорошо, вокруг этих два раза мы начинаем оптимизировать
2, используйте UglifyjsWebpackPlugin для открытия многопоточной упаковки
Первое, что нужно сделать, это стабилизировать хэш, но поскольку скорость упаковки в производственной среде слишком низкая, мы сначала оптимизируем скорость упаковки.По умолчанию пакет, предоставляемый webpack, является однопоточным.
const UglifyJSPlugin = require('uglifyjs-webpack-plugin')
module.exports = {
plugins: [
new UglifyJSPlugin({
parallel: true
})
]
}
Этот плагин предоставлен webpack3.Что касается младших версий webapck, то с ними нужно обращаться осторожно, но эффект очевиден.
Теперь время упаковки продукции51690ms
, на 1/3 быстрее, чем раньше
3, используйте многопоточность HappyPack для ускорения загрузчика
var HappyPack = require('happypack');
var os = require('os');
var happyThreadPool = HappyPack.ThreadPool({ size: os.cpus().length });
...
module: {
rules: [ {
test: /\.js[x]?$/,
exclude: /(node_modules|bower_components)/,
loader: 'happypack/loader?id=happybabel',
include: path.join(__dirname, 'static/assets/js')
}
}
plugins: [
new HappyPack({
id: 'happybabel',
loaders: ['babel-loader?cacheDirectory=true'],
threadPool: happyThreadPool,
cache: true,
verbose: true
}),
Погрузчик в атрибуте правил модуля выше был изначально Babel-Loader, но теперь он превращается в задачу, которая имеет идентификатор, и идентификатор соответствует экземпляру HappyPack в плагинах
На данный момент мы включили многопоточный режим babel-loader.
Теперь время упаковки продукции43855ms
, на 1/9 быстрее, чем раньше, это просто babel-loader, мы также можем открыть его для других загрузчиков
Затем разберитесь с загрузчиками типа less, css, style и т.д. Эти комбинации можно сделать за один раз
module: {
rules: [{
test: require.resolve('zepto'),
loader: 'exports-loader?window.Zepto!script-loader'
}, {
test: /\.js[x]?$/,
exclude: /(node_modules|bower_components)/,
loader: 'happypack/loader?id=happybabel',
include: path.join(__dirname, 'static/assets/js')
}, {
test: /\.less$/,
use: extractTextPlugin.extract({
fallback: "style-loader",
// use: ["css-loader" + (ENV ? '?minimize' : ''), "less-loader", "postcss-loader"]
use: ["happypack/loader?id=postcss"]
})
}]
}
plugins: [
new HappyPack({
id: 'happybabel',
loaders: ['babel-loader?cacheDirectory=true'],
threadPool: happyThreadPool,
// cache: true,
verbose: true
}),
new HappyPack({
id: 'postcss',
loaders: ["css-loader" + (ENV ? '?minimize' : ''), "less-loader",'postcss-loader'],
threadPool: happyThreadPool,
// cache: true,
verbose: true
}),
Таким образом, мы разобрались с babel, и в то же время мы также разобрались с загрузчиками, такими как css, less и postcss.
На картинке выше, счастливой [название задачи], вы можете видеть, что все поведение упаковки включает многопоточность, и эффект замечательный.
Теперь время упаковки продукции35130ms
, на этот раз скорость удвоилась по сравнению с первым неоптимизированным временем
4, используйте dll для разделения кода
После предыдущего процесса я, должно быть, понял, что чистые статические библиотеки и компоненты необходимо отделить от процесса упаковки, для которого требуется технология dll.
dll, по сути, заключается в том, чтобы упаковать содержимое с низкой частотой модификации или вообще без модификации и с большим количеством ссылок, и упаковать его отдельно.
Поскольку количество конфигурационных файлов резко возрастает после разработки dll, необходимо изменить структуру каталогов.
Например, на картинке выше разделите каждый веб-пакет и разделите все файлы конфигурации, такие как webpack.dev.js:
var base = require('./webpack.base.js');
var config = {
entry: require('./dev/entry.js'),
output: require('./dev/output.js'),
plugins: require('./dev/plugins.js'),
devtool: 'eval-source-map'
}
//把配置文件暴露出去;
module.exports = Object.assign(base,config);
хорошо, после того, как базовый разделенный веб-пакет завершен, мы создаем webpack.dll.libs.js для упаковки библиотеки классов
module.exports = {
libs: [
'react',
'react-dom',
'react-motion',
'react-redux',
'redux',
'axios',
'prop-types',
'classnames',
]
}
Измените плагин плагинов:
var webpack = require('webpack');
var dirVars = require('../common/dir.js');
var path = require('path');
var UglifyJsPlugin = require('uglifyjs-webpack-plugin');//多线程打包
var getDefaultPlugins = require('../common/plugins.js').getDefaultPlugins;
var AssetsPlugin = require('assets-webpack-plugin');//输出映射表
var plugins =[
new webpack.DllPlugin({
path: dirVars.dllLibsManiFest,
}),
new UglifyJsPlugin({
parallel: true,
cache: true
}),
new AssetsPlugin({
filename: 'static/dll/libs-rev-manifest.json'
}),
]
module.exports = plugins.concat(getDefaultPlugins())
Теперь выполните веб-пакет
Как видите, для упаковки всех библиотек классов требуется всего 1 с.
Добавьте в плагины:
new webpack.DllReferencePlugin({
manifest: 'static/dll/libs-rev-manifest.json'
}),
На данный момент, когда мы выполняем webpack.prod.js для упаковки, когда упакованный контент в библиотеках сканируется, он не будет повторно упакован.
4, начните продолжать ограничивать хэш
Упаковка была полностью сделана ранее, но она очень деструктивна, поэтому необходимо проверить, нет ли проблемы с хэшем системы.
case1: изменение js
Измените js бизнес-кода, добавьте комментарий и снова упакуйте его.
Вы видите, что хэш файла изменился, но, к сожалению, производитель также изменился
Решение: добавьте плагин webpack-md5-hash, после использования проверьте еще раз и обнаружите, что хэш vendorjs больше не меняется.
case2: меньше изменений
Изменился только один css хэш, без проблем
case3: изменение общедоступного метода в входе пакета
Выше был изменен плагин инструментов, который обычно используется на входе, и, наконец, хэш входа изменился, нет проблем.
case4: изменить компонент открытого метода js
В основном компоненты, на которые ссылаются несколько записей
Тест, изменен только хэш отдельно упакованных компонентов
case5: Измените компонент общедоступного метода меньше
изменился только один хэш
case6: добавить общедоступный компонент
Изменился только хеш компонентов
Время упаковки до оптимизации 180-200 с
оптимизация:
1,约束入口,严格明确入口文件筛选条件后
生产打包:74578ms
开发打包:24780ms
2,开启多线程压缩后
生产打包:51690ms
3,开启多线程编译
生产打包:35130ms
开发打包:15031ms
4,拆包
分解了打包过程,类库4s,组件4s,业务20s,总体30s左右
В конечном итоге процесс становится контролируемым, упаковка настраивается, а хэш сохраняется.