The Origin, Current State, and Solution of Frontend Scaffolding: Introducing the Leo Scaffold Framework

Frontend scaffolding arose as a productivity tool when business complexity increased, replacing the simple practice of copying an existing project and manually removing unwanted code.

As teams grew, copying became unreliable because source versions were hard to trace; projects began to store template code in Git repositories, requiring developers to clone the repo, delete the .git folder, and push to a new repository.

With many template repositories, developers faced the repetitive steps of cloning, cleaning, and pushing for each new project. To streamline this, teams wrapped the process in a CLI command (e.g., fe-cli projectName ) that automates cloning and setup.

Current Situation

The typical frontend development flow starts with a scaffold that only assists the initial project creation; subsequent steps—build tools, testing, linting, deployment approvals—are defined by team or project conventions, leading to inconsistencies across projects.

Scaffolds are often confined to small internal teams, limiting reuse and standardization across the organization, and new teams may still resort to manual copy‑paste due to lack of resources.

Leo's Solution

To address these pain points, the Leo scaffold was created. It provides a unified service that reduces the cost of maintaining individual scaffolds and enables teams to share templates and services.

Leo offers zero‑cost onboarding: new or existing teams can run leo init template to create a template folder, push it to the remote market, and later initialize projects with leo init your-template-name .

Unlike traditional scaffolds that only affect initialization, Leo’s modular design extends commands throughout the entire development lifecycle, covering building, testing, and deployment.

Developers can replace the default build tool (e.g., react-builder ) with alternatives like Gulp or Rollup by writing a custom builder module, which is then pushed to the market for shared use.

Leo Marketplace

When a template or builder is added, Leo automatically syncs it to the corresponding market, making internal resources available to a broader audience.

Design Philosophy

Leo’s architecture follows a three‑layer design: core logic layer, functional module layer, and business logic layer, with one‑way dependencies between layers.

Modules include Core (login, telemetry), CLI (command handling), Generator (template generation), and Builder (build and local development).

The template and builder markets are community‑maintained, allowing any developer to publish and share their assets, fostering a collaborative ecosystem.

How to Use

1. Create a project and install Leo.

2. Set up the scaffold project directory.

3. Declare the command entry in package.json .

4. Configure leo/core in bin/index.js and start the CLI.

For detailed configuration, refer to the official docs:

https://github.com/JDFED/leo/blob/master/docs/config.md

Additional documentation includes rc configuration and meta configuration links.

Leo is open‑source on GitHub ( https://github.com/JDFED/leo ) and welcomes contributions and stars.