Why Do Big Tech Companies Build Their Own Front‑End Scaffolding Tools?

Pre‑development phase

Without a scaffold developers must create separate configuration files such as webpack.config.js, rollup.config.js, eslint, prettier and jest, and remember distinct CLI commands for development, production build, preview and deployment. A scaffold bundles these into a few commands (e.g., npm run dev, npm run build, npm run preview, npm run deploy) and provides project templates (React, Vue, TypeScript, etc.).

Templates are declared in the scaffold’s

package.json

bin

field, mapping command names to entry scripts:

{
  "bin": {
    "create-vite": "index.js",
    "cva": "index.js"
  }
}

The entry script parses command‑line arguments, fetches the latest template repository and scaffolds the project. The scaffold also reads a vite.config file, builds a Rollup configuration and invokes the bundler. The core of this process is illustrated by the resolveConfig function:

export async function resolveConfig(
  inlineConfig: InlineConfig,
  command: 'build' | 'serve',
  defaultMode = 'development'
): Promise<ResolvedConfig> {
  let config = inlineConfig;
  let configFileDependencies: string[] = [];
  let mode = inlineConfig.mode || defaultMode;
  // some dependencies (e.g. @vue/compiler-*) rely on NODE_ENV for production‑specific behavior
  if (mode === 'production') {
    process.env.NODE_ENV = 'production';
  }
  ...
}

Scaffolds lock dependency versions and generate lock files, preventing accidental breakage from upstream updates or malicious releases.

Development phase

Providing templates

The scaffold offers multiple starter templates (plain JavaScript, TypeScript, Vue 3 + TS, etc.) and common assets such as favicon, title and preconnect links that can be configured centrally. It can also generate a monorepo shell before initializing a concrete project.

Convention‑based routing

Creating a pages directory makes each sub‑folder’s index file a page. Special pages like 404 or 500 enable error handling, and the scaffold can automatically add dynamic component imports. For permission‑protected routes two strategies are mentioned: completely block navigation, or allow entry but show a weak “request permission” prompt; the former yields a slightly poorer user experience.

Micro‑frontend integration

The scaffold can embed popular micro‑frontend frameworks such as single‑spa or qiankun into a B‑side template. In large organizations these frameworks are often wrapped with internal conventions, allowing developers to write ordinary components without knowing the underlying loading mechanism.

Pluggable feature plugins

Optional plugins (e.g., analytics, Sentry, permission handling) can be added. A permission plugin may redirect unauthenticated users on a 401 response and provide fine‑grained UI visibility based on menu configuration.

Network request layer

The scaffold configures environment‑specific request settings (base URL, timeout) for dev, test, pre‑release and production. It can also generate API client code from Swagger or Thrift definitions supplied by the backend.

Unified code style

Company‑wide prettier and eslint configurations are bundled, ensuring a consistent code style across all projects.

Build phase

Out‑of‑the‑box build support

The scaffold ships ready‑to‑use build pipelines that handle:

TypeScript / JavaScript

CSS, Less, Sass, Stylus, PostCSS, CSS Modules, Tailwind (including optional theming)

Images and SVGs (imported as URLs or components)

WebAssembly and other assets

Avoiding duplicate effort

When new tooling such as Vite, esbuild or SWC emerges, the scaffold team can release a beta version or a feature flag, sparing downstream developers from reinventing the wheel. An example SWC feature‑flag configuration is shown below:

/**
 * config sample
 * swc: { jsc: { parser: { syntax: "typescript", tsx: true } } }
 */
if (options?.swc) {
  return {
    test: /\.(t|j)sx?$/,
    use: {
      loader: "swc-loader",
      options: typeof options.swc === "object" ? options.swc : transformTsConfigToSwcConfig(),
    },
    exclude: /node_modules/,
  };
} else {
  return {
    test: /\.(t|j)sx?$/,
    use: {
      loader: "babel-loader",
    },
    exclude: /node_modules/,
  };
}

Pre‑commit phase

Commit hook

The scaffold can install a Git commit hook that performs lightweight checks:

Validate commit messages (e.g., feat/fix/chore…(project): description) using commitlint.

Run basic code‑quality checks with eslint and prettier.

Heavier checks such as unit tests remain in the CI pipeline to keep the hook fast.

Release phase

Push integrated with CI

The scaffold supplies a CI YAML file that runs on every push; if CI fails, subsequent merge or CD steps are blocked. It also provides a local publish command and a CI option to produce official release packages.