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

Pre‑development Phase

Developers use a company‑wide scaffold that bundles common commands ( npm run dev, npm run build, npm run preview, npm run deploy) and can integrate internal deployment environments.

The scaffold defines starter templates (e.g., react, react‑ts, vue, vue‑ts) in the

package.json

bin

field. The CLI reads command‑line arguments, fetches the latest template, and generates a project.

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

During project creation the CLI reads a vite.config file, builds a Vite config object, then creates the corresponding Rollup config before invoking Rollup.

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';
  }
  ...
}

Version Locking

The scaffold can lock dependency versions, preventing accidental upgrades or malicious releases that could break projects. Packages not covered by the scaffold remain managed via a lock file.

Development Phase

Template Provision

Multiple starter templates are offered (plain JS, plain TS, Vue 3 + TS, etc.). Common assets such as favicon, title, and preconnect links can be configured through a central config file. A monorepo shell template can also be provided for further initialization.

Convention‑based Routing

A pages directory is created by convention; each sub‑folder’s index becomes a page. Special pages like 404 or 500 enable error handling. Dynamic component loading is integrated by default. For permission‑protected pages, two strategies exist: block navigation entirely or allow entry with a weak “request permission” prompt; the former may feel slower because the check occurs after navigation.

Micro‑Frontend Integration

The scaffold can embed a micro‑frontend framework (e.g., single‑spa, qiankun) into a B‑side template. In large companies the framework may be further wrapped, but developers still write components as usual without needing to know the underlying loading mechanism.

Pluggable Feature Plugins

Optional plugins such as analytics, Sentry, and permission handling can be added. The permission plugin can intercept 401 responses from single‑sign‑on systems and redirect to a login page, and it can also control page‑level visibility based on menu configuration.

Network Request Layer

The scaffold configures request settings per environment (dev, test, pre‑release, production), adjusting baseURL, timeouts, etc. It can also generate API client code from backend‑provided Swagger or Thrift definitions.

Prettier & ESLint

Company‑wide formatting and linting rules are bundled, ensuring a unified code style across all projects.

Build Phase

Out‑of‑the‑Box Build Support

The scaffold supplies default configurations for common file types:

TypeScript / JavaScript

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

Images and SVGs (imported as sources or components)

WebAssembly and other assets

Avoiding Duplicate Work

When new tooling such as Vite, esbuild, or SWC emerges, the scaffold team can release a beta version or a feature flag, allowing developers to adopt the upgrade without each team reinventing the wheel.

Example SWC feature‑flag configuration:

/**
 * 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 Hooks

The scaffold can install Git commit hooks that perform lightweight checks:

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

Run initial code‑quality checks such as ESLint and Prettier.

Heavier checks (unit tests, full linting) remain in the CI pipeline to keep the hook fast.

Release Phase

Push Integrated with CI

Because commit hooks can be bypassed, the scaffold also supplies a CI YAML file that runs a double‑check on push. If CI fails, subsequent merge or CD steps are blocked.

Publishing can be done locally via a scaffold publish command or automatically through a CI job that builds the final package.