2017-04-11 393 views
1

我们很难尝试迁移到我们的项目,该项目基于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 

在这两种情况下,它是高级模块优化步骤,其中大部分时间消耗。 我不明白为什么有一个高级优化在非生产构建,我不知道为什么要花这么多时间。

我想知道是否有任何方法可以深入了解耗时的步骤,以及是否有可能在开发模式中禁用该优化。

谢谢!

+0

的WebPack CLI标志输出时序信息:'的WebPack --progress --profile' – joemaller

回答

0

一些详细得多的挖掘后,我们结束了一个破解作弊的WebPack。 在我们的系统中,我们有几十个异步加载的块和一些扩展循环依赖关系,这导致了很多父类很多的块。 因此,主要耗时的任务是执行内置的RemoveParentModulesPlugin。 由于长链模块链中有很多父母,所以这个插件需要做额外的工作。

我们的解决方案是(只在开发模式)添加新的自定义插件,它删除的每一个模块的父母为运行在本地机器上的应用程序时,我们不需要这种优化。

这是我们的自定义插件的代码,如果有人发现它在未来有用:

function AvoidParentModulesOptimizationPlugin() {} 
AvoidParentModulesOptimizationPlugin.prototype.apply = function(compiler) { 
    compiler.plugin('compilation', function(compilation) { 
     compilation.plugin(["optimize-chunks-basic", "optimize-extracted-chunks-basic"], function(chunks) { 
      // We cheat webpack to think there are no parents to optimize 
      // so recompilation time is quite low on development mode 
      chunks.forEach(function(chunk) { 
       chunk.parents = []; 
      }); 
     }); 
    }); 
}; 
1

我们的团队也有同样的问题。我们已经确定,使用require.ensure会导致速度放慢,这为套件提供了动态加载。我们已经在这里旗

https://github.com/webpack/webpack/issues/4716

要解决此问题的问题,我的队友发现使用巴贝尔插件,剥离require.ensure在开发环境解决方法。它将高级模块优化时间缩短到了几毫秒。随着周围的工作,我们的连续生产时间从8秒减少到1.5秒。

https://www.npmjs.com/package/babel-plugin-remove-webpack

+0

感谢您的光纤收发器小费。 这不是我们的情况,但我看到您选择的选项是不使用开发模式下的异步加载。 我们正在努力保持这一点,因此了解异步和它可能导致的问题对我们非常重要。 – PaquitoSoft