Why Traditional Frontend Scaffolds Fail and How Cloud‑Based Engineering Solutions Solve It

Evolution of Scaffolding

In frontend development, scaffolding is responsible for initializing a project and forms the foundation for subsequent work. Early approaches involved copying an existing project and manually removing business‑specific code. As product velocity increased, teams moved to maintaining a template repository that was cloned, stripped of its .git directory, and pushed to a new repository.

To reduce this repetitive process, a CLI command (e.g., fe-cli projectName) was created, leveraging Node.js libraries such as commander, inquirer, and shelljs. The CLI can also support template selection, enabling different project types to be generated with a single command.

Maintenance Costs

Maintaining a custom scaffolding tool can be costly for teams that are not dedicated to infrastructure. The tool’s functionality is limited to generating code; once the project is created, the scaffolding is rarely used again.

Version upgrades pose another challenge: unless the scaffolding forces a version check, users may continue to invoke an outdated version. A possible mitigation is to require execution via npx instead of a globally installed package ( npm i -g), adding a small overhead but ensuring the latest features are used.

Engineering Scheme – Code Initialization

Within ByteDance’s internal “Goofy Studio” (an integrated frontend development platform), the solution is called an “Engineering Scheme”. It is not merely an upgraded scaffold but a collection of best‑practice configurations covering the entire frontend lifecycle. Code initialization is one component of this scheme.

The scheme offers three initialization methods: template, cloud‑based CLI, and webshell. All methods ultimately generate initial code, create a new repository, and push the code, but they run inside a cloud container, eliminating local environment inconsistencies and requiring no manual intervention.

Template Method

This simplest method uses a compressed template package (tar). During initialization, the package is uploaded directly to the newly created repository.

Cloud CLI Method

The cloud CLI runs predefined commands inside a container, uploads the resulting artifacts as template code, and supports configurable aspects such as globally installed packages, execution commands, output directories, and ignored files.

Example of a Vue project initialization configuration generated by @byted/studio-cli:

{
  "schema": {
    "key": "gulu",
    "isObject": true,
    "items": [
      {
        "key": "template",
        "label": "select template",
        "items": [
          {"key": "http-server", "label": "http-server"},
          {"key": "http-server-ts", "label": "http-server-ts"},
          {"key": "thrift-server", "label": "thrift-server"},
          {"key": "thrift-server-ts", "label": "thrift-server-ts"},
          {"key": "plugin", "label": "plugin"},
          {"key": "plugin-ts", "label": "plugin-ts"}
        ]
      }
    ]
  },
  "customUIConfig": {
    "template": {"ui": "Select"}
  }
}

To demonstrate schema usage, a Gulu project (an internal framework) is generated with a template‑selection dropdown, configured as follows:

Webshell Method

This method further lowers the configuration barrier by allowing users to interact with a web‑based shell that mimics the CLI execution without any schema forms. It also serves as a fallback for the CLI method when schema updates lag behind CLI upgrades.

Summary

Replacing traditional scaffolds with the Engineering Scheme’s code‑initialization configurations ensures that each project is created with the latest CLI version inside a fresh container, maximizing success rates and automating the entire setup process.

Engineering Scheme Marketplace

The best‑practice configurations are packaged into an “Engineering Scheme Marketplace”, enabling any team to adopt standardized solutions, maintain technical consistency, and extend influence beyond the organization.