swc gives 2x boost in webpack-dev-server, but basically nothing in webpack-cli release?

[bes]

Hi!

I am trying out swc and am really enjoying the performance boost in webpack when using webpack-dev-server, initial build time went from 30+ seconds to about 15 seconds.

However, when I use webpack-cli to build, I don't see the same boost. Both swc and ts-loader leave me with about 45 seconds build time. What could be the reason for that?

If you want me to share some part of my config I can probably do that, depending on what it is.

Thanks!

[kdy1]

I guess type checker (tsc) is eating all the time when you build (for production), but type checking is working as a non-blocking mode in development mode.

This is an uneducated guess, but many typescript projects use such config because the type checker is too slow to use synchronously in dev mode.

[bes]

Yes the type checker takes a long time, but I don't understand why that explains that the total time did not improve for production builds? I was expecting to see at least some improvement?

[kdy1]

I think your webpack is configured to build with tsc on production mode.
If not, can you share some parts of your config?

[bes]

Build command: NODE_ENV=production node_modules/.bin/webpack-cli --config app/webpack.config.js --env.prod --bail --env.favicons

webpack config (removed sensitive stuff, hopefully usable):

const webpack = require("webpack");
const HtmlWebpackPlugin = require("html-webpack-plugin");
const MiniCssExtractPlugin = require("mini-css-extract-plugin");
const path = require("path");
const FaviconsWebpackPlugin = require("favicons-webpack-plugin");
const CopyWebpackPlugin = require("copy-webpack-plugin");
const ForkTsCheckerWebpackPlugin = require("fork-ts-checker-webpack-plugin");
// const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

const nodeModulesPath = path.join(__dirname, "../", "node_modules");

const aliasConfig = require("./webpack.alias.js");

module.exports.createConfig = (config) => {
    /**
     * Parameter debug true if running from webpack-dev-server, false otherwise
     * Parameter env command line environment, supplied by webpack
     */
    return (debug) => (env) => {
        const entry = {
            main: [path.join(config.srcPath, config.entryFile)],
        };

        const module = {
            rules: [
                {
                    test: /\.js$/,
                    exclude: /node_modules/,
                    use: {
                        loader: "swc-loader",
                    },
                },
                {
                    test: /\.tsx?$/,
                    exclude: /node_modules/,
                    use: {
                        loader: "swc-loader",
                    },
                },
                {
                    // Process source maps included in transpiled ts-files
                    enforce: "pre",
                    test: /\.js$/,
                    loader: "source-map-loader",
                },
                {
                    test: /^((?!\.module).)*css$/,
                    use: [debug ? "style-loader" : MiniCssExtractPlugin.loader, { loader: "css-loader" }],
                },
                {
                    test: /^((?!\.module).)*less$/,
                    use: [
                        debug ? "style-loader" : MiniCssExtractPlugin.loader,
                        { loader: "css-loader" },
                        { loader: "less-loader" },
                    ],
                },
                /** more css, url, file-loaders */
            ],
        };

        function getWebpackPluginFilename(filename) {
            if (debug) {
                return filename;
            }
            return `../${filename}`;
        }

        let selected;
        let isProd;
        if (env.dev) {
            /** Select env */
        } else {
            throw new Error("Can not proceed without an environment");
        }

        const plugins = [];

        plugins.push(
            new webpack.DefinePlugin({
                /* stuff */
            }),
        );
        plugins.push(
            new HtmlWebpackPlugin({
                inject: true,
                title: selected.titlePrefix + config.title,
                template: path.join(config.srcPath, "index.html"),
                filename: getWebpackPluginFilename("index.html"),
            }),
        );

        if (env.favicons) {
            plugins.push(
                new FaviconsWebpackPlugin({
                    /* stuff */
                }),
            );
        }
        plugins.push(
            new MiniCssExtractPlugin({
                filename: debug ? "[name].css" : "[contenthash].css",
                chunkFilename: debug ? "[name].css" : "[chunkhash].css",
            }),
        );
        plugins.push(
            new ForkTsCheckerWebpackPlugin({
                typescript: {
                    memoryLimit: 3072, // MiB
                },
            }),
        );
        // Specify which locales to include for moment
        plugins.push(new webpack.ContextReplacementPlugin(/moment[/\\]locale/, /(zh-cn|sv|en-gb).js/));

        // Uncomment when doing size analysis
        // plugins.push(new BundleAnalyzerPlugin());

        const optimization = {
            splitChunks: {
                chunks: "all",
            },
        };

        if (!debug) {
            const sourceMapUrl = isNightwatch
                ? `http://${env.listenAddress}:${config.port}/js/`
                : "http://localhost:8080/js/";

            plugins.push(
                new webpack.SourceMapDevToolPlugin({
                    filename: "[file].map",
                    append: `\n//# sourceMappingURL=${sourceMapUrl}[url]`,
                }),
            );

            // Make chunks more deterministic by using module hashes and chunk names for loading instead of randomly assigned ints
            // In webpack "next" there is supposed to be a "deterministic" setting. Keep an eye out for it.
            optimization.moduleIds = "hashed";
            optimization.chunkIds = "named";
        }
        if (config.emitWellKnown) {
            plugins.push(
                new CopyWebpackPlugin([
                    {
                        from: path.join(config.mainPath, "well-known/"),
                        to: getWebpackPluginFilename(".well-known"),
                    },
                ]),
            );
        }

        return {
            target: "web",
            mode: debug ? "development" : "production",
            devtool: debug ? "source-map" : undefined,
            entry: entry,
            resolve: {
                extensions: [".js", ".tsx", ".ts"],
                modules: [config.srcPath, "../node_modules", "src/main/js"],
                alias: aliasConfig.resolve.alias,
            },
            resolveLoader: {
                modules: [nodeModulesPath],
            },
            output: {
                path: config.destPath,
                publicPath: debug ? "/" : "/js/",
                filename: debug ? "[name].js" : "[chunkhash].js",
                chunkFilename: debug ? "[name].js" : "[chunkhash].js",
            },
            module: module,
            plugins: plugins,
            devServer: {
                devHotReloadPort: config.port,
                /* stuff */
            },
            optimization: optimization,
        };
    };
};

[kdy1]

Oh, I was wrong.
It seems webpack itself is eating all the time.

Can you try profiling with https://webpack.js.org/plugins/profiling-plugin/ ?

[bes]

Ok, but I still don't understand. Let's consider these equations:

webpack-dev-server:

oldTime = time('ts-loader') + time('other-webpack-stuff') = 32s
newTime = time('swc')       + time('other-webpack-stuff') = 15s

release:

oldTime = time('ts-loader') + time('TerserPlugin') + time('ForkTsCheckerPlugin') + time('other-webpack-stuff') = 47s
newTime = time('swc')       + time('TerserPlugin') + time('ForkTsCheckerPlugin') + time('other-webpack-stuff') = 45s

I might be incredibly slow in the brain right now, but what is webpack doing in release mode that makes the gains from swc compiling unimportant? Is there a parallel step that I am not realizing?

30 Minutes later

So I did a profile of "old" release mode as well, and I can see that the difference between old and new is that in the new case, i.e. with swc, ForkTsCheckerWebpackPlugin is using 15 s at the end, but in the old one it is not.

• The old version invokes ForkTsCheckerWebpackPlugin 386 times.
• The new version invokes ForkTsCheckerWebpackPlugin 387 times.

The 387th invocation of ForkTsCheckerWebpackPlugin (with swc enabled) eats up all the 15 second gain by running ForkTsCheckerWebpackPlugin for 15 seconds.

See this new screenshot of old - there is no ForkTsCheckerWebpackPlugin at the end!

Why???

[Brooooooklyn]

Have you set transpileOnly: true in ts-loader? If not I think maybe the ts-loader produced .tsbuildinfo in production mode, and ForkTsCheckerWebpackPlugin consumed the .tsbuildinfo cache and just do nothing.

[bes]

Yes,

  {
      test: /\.tsx?$/,
      use: [
          babelLoader,
          {
              loader: "ts-loader",
              options: {
                  transpileOnly: true,
              },
          },
      ],
      exclude: /node_modules/,
  },

[kdy1]

Seems like the ts checker plugin does type checking at least once.

I think it should start when the build starts, but it starts working after the terser pass.

[bes]

In the case of ts-loader, ForkTsCheckerWebpackPlugin is invoked 386 times, every invocation is very short.
In the case of swc, ForkTsCheckerWebpackPlugin is invoked 387 times, every invocation except the last one is very short.

It seems to me that for some reason, ForkTsCheckerWebpackPlugin either does an extra (unneeded?) check in the case of swc, or that it is missing one check at the end for ts-loader.