How We Built vbuilder: Streamlining Frontend Engineering at Weidian

V0.0

Weidian’s front‑end engineering began with an internal product called vbuilder , released externally as the open‑source bio‑cli. Early on the team faced several pain points:

Repetition : each project required a new scaffold (webpack, gulp, etc.).

Mixing : scaffold files and business code lived together.

Package confusion : package.json contained both scaffold and business dependencies.

Hard to update : once a scaffold version was chosen it rarely changed (e.g., many projects stayed on webpack 1.0).

Collaboration cost : diverse tech stacks increased the effort to understand project configurations.

These issues motivated the development of vbuilder, initially released as a command‑line tool (V0.0).

V1.0

vbuilder V1.0 introduced the following capabilities:

Default command set : built‑in commands such as mock, update, help.

Silent updates : users install once and receive automatic updates.

Scaffold convergence : scaffold configuration is hidden and centrally managed, letting developers focus on business logic.

Open integration : supports any tech stack (e.g., vue, react, angular, weex).

Plugin system : extensible command set for custom logic.

After adopting V1.0, the team observed improvements:

Convenience : a new project can be created with a single command.

Purity : only business files remain in the project directory.

Up‑to‑date : scaffolds are unified and updated together.

Collaboration : most effort focuses on business logic, not configuration.

Openness : various scaffolds (e.g., weex, vms, backend admin, server‑side projects) can be plugged in.

Unified tech updates : the team can roll out new stack versions quickly.

V1.0 was guided by three principles: efficiency (saving developers’ time), shared responsibility (encouraging contributors to maintain scaffolds and plugins), and usability (keeping the tool simple and attractive).

Problems in V1.0

Closedness : highly customized configuration needs were hard to implement because scaffold configuration was hidden.

Plugin conflicts : different plugins could define the same command (e.g., run or init), causing both to execute.

V2.0

V2.0 aims to resolve V1.0’s shortcomings while providing a clearer roadmap, still delivered as a CLI.

Opening the configuration

Configuration can now be hidden or exposed on demand, allowing custom development when needed. vbuilder tracks which projects use custom scaffolds and can distribute common toolkits accordingly.

Resolving plugin conflicts

Detect duplicate commands and prompt the user to run all or select one.

Scope command effectiveness using custom conditions.

Declare built‑in commands with declareDefault() and allow plugins to block them with preventDefault().

Example of a conditional command:

commander
.command('show [param]')
.effect(cwd => fs.existsSync(path.join(cwd, 'xx.show')))
.description('My custom command')
.action((param, options) => {
  console.log('my show');
});

Defining a built‑in command:

commander
.command('init [param]')
.declareDefault()
.description('Built‑in init command')
.action((param, options) => {
  console.log('init inside');
});

Plugin overriding the built‑in command:

commander
.command('init [param]')
.preventDefault()
.description('Plugin init command')
.action((param, options) => {
  console.log('init inside');
});

New V2.0 features

Support for Chrome extension ES6/7 development.

Rapid component‑library creation.

Fast JavaScript utility‑library scaffolding.

Quick access to documentation libraries.

Through the plugin architecture, developers can continuously extend vbuilder’s capabilities.

V3.0 (Future)

Cloud IDE integration (internal platform already exists).

Custom VSCode IDE for large teams.

Further cloud‑nativeization.

These are the current practices and thoughts on front‑end engineering at Weidian, shared in hopes of helping other teams.