Too long build

Do you want to request a feature or report a bug?

Probably it’s bug…

What is the current behavior?

2017-03-23 16 10 41

If the current behavior is a bug, please provide the steps to reproduce.
I build a simple example with one ‘import’ = angular library.
After update to 2.3.1 version I noticed that build is too long.

What is the expected behavior?

The same project with 2.2.1 webpack.

2017-03-23 16 36 54

If this is a feature request, what is motivation or use case for changing the behavior?

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

Author: Fantashit

7 thoughts on “Too long build

  1. Sounds like a similar issue to babel/babel#3565 where because you read from this.generatedCode, V8 will flatten the string into contiguous memory on access. When concatenating a very large string, reading the string content should be avoided until you are done appending.

  2. I am also experiencing this issue on 2.3.3.

    Running: time NODE_ENV=production webpack -p --config ./config/

    Hash: 30f6e4ace738569c758f
    Version: webpack 2.3.3
    Time: 62029ms
    npm run js:production -- --progress  64.02s user 1.14s system 103%% cpu 1:02.97 total

    Here is my production webpack config file:

    const webpack = require('webpack')
    const path = require('path')
    const env = require('./env')
    const paths = require('./paths')
    const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin
    if (env['process.env.NODE_ENV'] !== '"production"') {
      throw new Error('Production builds must have NODE_ENV=production.')
    module.exports = {
      bail: true,
      devtool: 'cheap-module-source-map',
      entry: require('./entryPoints'),
      output: {
        path: paths.appBuild,
        pathinfo: true,
        filename: '[name].bundle.js',
        publicPath: paths.appPublic,
      resolve: {
        modules: [
      module: {
        rules: [
            test: /\.js$/,
            enforce: "pre",
            loader: 'eslint-loader',
            include: paths.appSrc,
            options: {
              configFile: path.join(paths.appConfig, 'eslint.js'),
              useEslintrc: false
            test: /\.js$/,
            loader: 'babel-loader',
            exclude: /node_modules/,
            include: [paths.appSrc],
        noParse: [
          new RegExp('node_modules/localforage/dist/localforage.js'),
      plugins: [
        new webpack.LoaderOptionsPlugin({
          minimize: true,
          debug: false
        new webpack.DefinePlugin(env),
        new webpack.optimize.UglifyJsPlugin({
          sourceMap: true,
          beautify: false,
          comments: false,
          drop_console: false,
          drop_debugger: true,
          compress: {
            screw_ie8: true,
            warnings: false,
          mangle: {
            screw_ie8: true,
            keep_fnames: true,
      ].concat(env.analyzeBundles ? [new BundleAnalyzerPlugin()] : [])
  3. This seem to be a different issue. When facing incorrect long build times try this:

    Make sure to use the lastest LTS node.js version.

    Make sure to use the lastest webpack version.

    node --inspect-brk node_modules/webpack/bin/webpack.js ...

    In chrome open chrome://inspect

    Open the devtools for node.js

    Go to the profiler and start a CPU profile (it automatically continues execution):


    Watch the commandline and press Stop when the build has finished.

    Take a look at the flame graph. Take a screenshot. Identify slow parts.


    Save the profile into a file.

    File a new issue with your findings.

Comments are closed.