我们很难尝试迁移到我们的项目,该项目基于requirejs。缓慢的webpack构建时间(高级模块优化)
经过几个星期的努力,我们用webpack复制了我们当前的项目状态后,我们遇到了性能问题。
我们正在使用webpack版本2.3.3。
目前我们有240个模块和58个块。
我们的问题是,当我们在手表推出的WebPack模式开发(或使用的WebPack-dev的服务器),每次我们修改一个文件,我们不得不等待10秒左右吧。
这里是我们的WebPack开发配置:
{
context: path.resolve(__dirname),
entry: {
'app-std': [
'main',
'plugins/base-component',
'controllers/base-controller',
'widgets/base-widget',
'usertiming'
]
},
output: {
path: path.resolve('./dist/js'),
filename: '[name].js',
publicPath: '/js/'
},
resolve: {
modules: ['public/js', 'node_modules'],
alias: {
'uuid': path.resolve(__dirname, 'public/vendor/uuid.js/dist/uuid.core.js'),
'jsLogger': 'js-logger',
'jqueryCookie': 'js-cookie',
'jqueryValidation': path.resolve(__dirname, 'node_modules/jquery-validation/dist/jquery.validate.js'),
'jQueryXDomainRequest': 'jquery-ajax-transport-xdomainrequest',
'dust': 'dustjs-linkedin',
'dust.core': 'dustjs-linkedin',
'dustHelpers': 'dustjs-helpers',
'bootstrapSelect': 'bootstrap-select',
'bootstrapDropDown': path.resolve(__dirname, 'node_modules/bootstrap/js/dropdown.js')
}
},
module: {
rules: [
{
test: /\.jsx?$/,
loader: 'babel-loader',
exclude: /(node_modules)/,
options: {
presets: [['es2015', { modules: false }]/*, 'react'*/],
plugins: ['syntax-dynamic-import'],
cacheDirectory: true
}
}
]
},
plugins: [
new webpack.DefinePlugin({
'process.env': {
'NODE_ENV': JSON.stringify('local')
}
}),
new webpack.ProvidePlugin({
$: 'jquery',
jQuery: 'jquery'
}),
new webpack.IgnorePlugin(/^\.\/locale$/, /moment$/)
],
devtool: 'cheap-module-eval-source-map',
devServer = {
https: true,
port: 7070,
host: '0.0.0.0',
headers: { 'Access-Control-Allow-Origin': '*' }
},
stats: {
chunks: true,
chunkModules: true,
modules: true
}
}
这些是初步搭建了统计:
6185ms building modules
65ms sealing
2ms optimizing
1ms basic module optimization
12ms module optimization
7906ms advanced module optimization
1ms basic chunk optimization
0ms chunk optimization
1ms advanced chunk optimization
0ms module and chunk tree optimization
12ms module reviving
2ms module order optimization
3ms module id optimization
2ms chunk reviving
6ms chunk order optimization
9ms chunk id optimization
22ms hashing
0ms module assets processing
214ms chunk assets processing
2ms additional chunk assets processing
1ms recording
0ms additional asset processing
0ms chunk asset optimization
2ms asset optimization
192ms emitting
如果我们modifiy我们的模块之一的WebPack会触发重建,我们得到这个数字:
38ms building modules
38ms sealing
1ms optimizing
1ms basic module optimization
1ms module optimization
7470ms advanced module optimization
1ms basic chunk optimization
0ms chunk optimization
1ms advanced chunk optimization
0ms module and chunk tree optimization
3ms module reviving
0ms module order optimization
4ms module id optimization
3ms chunk reviving
1ms chunk order optimization
4ms chunk id optimization
14ms hashing
0ms module assets processing
1ms chunk assets processing
1ms additional chunk assets processing
0ms recording
0ms additional asset processing
1ms chunk asset optimization
0ms asset optimization
1ms emitting
在这两种情况下,它是高级模块优化步骤,其中大部分时间消耗。 我不明白为什么有一个高级优化在非生产构建,我不知道为什么要花这么多时间。
我想知道是否有任何方法可以深入了解耗时的步骤,以及是否有可能在开发模式中禁用该优化。
谢谢!
的WebPack CLI标志输出时序信息:'的WebPack --progress --profile' – joemaller