Speeding up Webpack and ts-loader

As your project complexity increases, the chances for your Webpack to become slower are extremely high.

For us at Airtame, we have a massive application built around Electron and React and we recently stumbled upon a massive slowdown in our build due to ts-loader.

While we haven’t debugged the problem to the very bottom, we found a way to completely “unstuck” around build and made it bundle in around 20 seconds (on Dell XPS 9560) from around 4-5 minutes before the optimization.

To get to the bottom of it, you will need a Webpack plugin called fork-ts-checked and some Webpack configuration changes.

For the tslint-loader, you will want to make sure to disable or remove typeCheck property in case it’s set to true.

{
    enforce: 'pre',
    test: /\.tsx?$/,
    loader: 'tslint-loader',
    exclude: /node_modules/,
    options: {
        emitErrors: true,
        failOnHint: false,
        configFile: 'tslint.json',
        typeCheck: true // You want to make sure this is removed or set to false
    }
}

For the ts-loader part, you want to make sure to set transpileOnly to true.

{
    test: /\.tsx?$/,
    exclude: /node_modules/,
    use: {
        loader: 'ts-loader',
        options: {
            onlyCompileBundledFiles: true,
            transpileOnly: true
        },
    },
}

Keep in mind that the rest of the configuration pasted here is relative to your project so the rest of the stuff might be redundant to you as you are maybe using different configuration for specific properties.

Lastly, you want to integrate the fork-ts-checked plugin.

This plugin will move ts-loader to the different process (or processes depending on how many cores you allocate to it) and keep running in parallel. For some reason that we haven’t debugged yet, ts-loader added like 3 or 4 minutes time to our bundling process and while we are devoting time to take a look at this, this approach solves it and you should be pretty happy with it.

After installing and including the above plugin, make sure to add it under your webpack plugins array. It should look something like this:

new ForkTsCheckerWebpackPlugin({ memoryLimit : 10000, workers: 2 })

memoryLimit option is only necessary if you are building a massive project and node starts giving you memory errors. When it comes to workers, it depends how many CPU cores you want to devote to this, one should be just fine.

This hopefully resolved the same issue we had. After we’ve done this, we will continue looking into ways of speeding up the bundling process and optimizing around it as much as we can.

If you have some suggestions and would like to help us optimize more, please share it in the comment section below.