Optimizing Build Performance of a Large Multi‑Project Frontend Application with Dynamic Entry Points and Loader Caching

The author, a front‑end engineer at 360, took over an internal cloud platform project (named H) that had grown into a massive codebase containing dozens of sub‑projects built with React, Webpack, Reflux, MobX and many custom libraries.

Because the project accumulated over years, the development experience deteriorated: launching webpack‑dev‑server took about 90 seconds on an 8 GB‑RAM MacBook, and each code change required an additional 35‑second rebuild, making debugging painful.

To address the slowdown, the author devised a three‑step optimization strategy: (1) make the Webpack entry points dynamic so only the needed sub‑project is built, (2) replace file‑system writes and child_process calls with environment‑variable driven builds, and (3) cache the costly loaders.

First optimization – dynamic entry configuration : The original multi‑entry Webpack config was extracted into entry.config.js. A small entry.js file stores the target project name (e.g., projectA) and is referenced by the dev and build scripts. Example snippet:

let projectName = process.argv[2] || "all";
let fs = require("fs");
fs.writeFileSync("./config/entry.js", `exports.entryName = '${projectName}'`);
let exec = require("child_process").execSync;
exec("npm run serve", { stdio: "inherit" });

The package.json scripts were updated to run node config/dev.js (for development) and node config/build.js (for production), allowing commands such as npm start projectA to build only the selected sub‑project.

Second optimization – environment‑variable build : To avoid writing files and spawning child processes, the author switched to using cross‑env to set an APP_ENTRIES environment variable. The build script reads this variable (defaulting to "all" if unset) and passes it directly to Webpack. Example snippet: let entryName = process.env.APP_ENTRIES || "all"; This change eliminated unnecessary I/O and made the build process more elegant.

Third optimization – loader caching : The most time‑consuming loaders were babel-loader and eslint-loader. By enabling cacheDirectory in babel-loader and inserting cache-loader before the expensive loaders, the compiled results are stored on disk and reused when files haven’t changed. Example configuration:

module.exports = {
  module: {
    rules: [{
      test: /\.js$/,
      use: ["cache-loader", "babel-loader", "eslint-loader"],
      include: path.resolve('src')
    }]
  }
};

After applying all three optimizations, the build time for the most frequently used sub‑project dropped from over 100 seconds to about 40 seconds, and further tuning reduced it to roughly 17 seconds—a more than 60 % improvement that dramatically enhanced developer experience.

In conclusion, dynamically selecting entry points, leveraging environment variables, and caching loader output together provide a practical template for speeding up large front‑end monorepos, while future work may explore even finer‑grained module‑level builds.