How IMFLOW Was Re‑Engineered: From Monolithic Tool to Modular Build‑Kit Architecture

1. Upgrade Background

IMFLOW is an engineering tool that integrates Webpack best practices, covering project initialization, template creation, development standards, compilation, and build. It also serves as an ecosystem for various business scenarios (Web, SCF, LIB). While functional, the tool accumulated technical debt and needed a redesign.

Too many responsibilities as a scaffold and tool, heavy plugin system tightly coupled with business logic, leading to long command execution times (≈3 s for imf create).

Ecology fragmentation: IMF, IMFS, and IMFL share core code but require duplicate modifications across tools, increasing maintenance effort.

2. Upgrade Goals

Decouple core workflow from business code, creating IMFLOW‑CORE .

Make each build tool a plug‑in Build Kit loaded by CORE.

Lightweight the kits so startup time is under 1 s.

Unify configuration, dependency management, and environment logic.

Expose a standardized API managed by CORE for reporting, config access, and command registration.

Support FEFlow plugins for community compatibility.

Maintain backward compatibility with minimal configuration changes.

3. Refactoring Analysis

3.1 Refactoring Patterns

3.1.1 Demolition Pattern

Replace the old system with a brand‑new one, running both in parallel during migration.

Pros: complete separation, eliminates legacy baggage.

Cons: risky migration, high human cost.

3.1.2 Strangulation Pattern

Introduce new modules to replace old ones incrementally.

Pros: full feature coverage, stable service.

Cons: risk driven by requirements, may degrade to demolition.

3.1.3 Renovation Pattern

Isolate and refactor only the parts that need fixing while keeping the rest unchanged.

Pros: preserves original requirements, no external impact.

Cons: longer refactor time, higher technical cost.

3.1.4 Pattern Selection

Given IMFLOW’s characteristics, a hybrid approach—"core demolition, upper‑layer renovation"—was chosen: replace the core entirely while only minimally adjusting business‑specific modules.

3.2 Refactor Content

Consolidate IMF, IMFS, and IMFL into a single system. Each build kit (e.g., create, dev, build) is loaded as a plug‑in into IMFLOW‑CORE . The architecture is illustrated as a “Nezha” model: a shared core (organs) with plug‑in arms and legs.

4. Terminology

Term

Explanation

CORE

Core module cluster of the new architecture.

BuildKit

Build kit derived from the original tools, managed by CORE.

Plugin

Both generic and business‑bound plugins consumed by CORE or BuildKit.

IMFLOW

Legacy web build tool, now renamed BuildKit‑Web.

IMFLOW‑SCF

Legacy cloud‑function build tool, now BuildKit‑SCF.

IMFLOW‑LIB

Legacy library build tool, now BuildKit‑LIB.

FEFLOW

Tencent OTeam’s engineering solution with its own plugin ecosystem.

Commander.js

Node.js command‑line management library.

5. Legacy Architecture Analysis

5.1 Architecture Diagram

All three tools share a similar structure but differ in configuration files and some commands (e.g., publish for IMFL, deploy for IMFS).

5.2 Differences

Configuration file names differ (imflow.config.js, imflow‑scf.config.js, etc.).

Command registration uses Commander.js with a thin wrapper.

Reporting logic varies across tools.

Plugin loading is similar but lacks on‑demand loading.

5.3 Startup Time Issues

5.3.1 Module Loading

Eagerly importing all modules blocks the single‑threaded Node.js event loop.

import loadConfig from "@tencent/imflow-cli-utils/load-config"
import { logger, spinner } from "@tencent/imflow-common"
import program, { Command } from "commander"
import fs from "fs-extra"
import inquirer from "inquirer"
import lodash from "lodash"
import path from "path"
import resolveFrom from "resolve-from"
import webpack from "webpack"
import WebpackChain from "webpack-chain"

5.3.2 Update Check

Update checks run on every command, adding 1.5‑2.5 s overhead.

5.3.3 Plugin Loading

All plugins are loaded at startup even if only a subset is needed.

private applyPlugins() {
  const buildInPlugins = [
    require("./plugins/command-create"),
    require("./plugins/config-base"),
    // ... other built‑in plugins
  ];
  // load custom plugins
}

6. Architecture Design

6.1 Overall Diagram

The system is divided into four layers:

CLI interaction layer.

File storage layer (global vs. local).

CORE logic layer (package manager, commander, config system, plugin system).

Market plugin ecosystem (business plugins, generic plugins, build kits).

6.2 Directory Structure

.
├── bin/cli.ts               # entry point
├── command/                 # command registration
│   ├── buildKit.ts
│   └── plugin.ts
├── modules/
│   ├── configModule/
│   ├── packageManager/
│   └── pluginModule/
└── utils/                   # helpers (update check, logger, etc.)

7. Core Modules

7.1 CLI Command Module

Registers global options (e.g., --no-check-latest, --debug, -k,--build-kit, -g,--global) and initializes IMFLOW‑CORE.

program.option("--no-check-latest", "Do not check latest version", false);
program.option("--debug", "Output debug info", false);
program.option("-k,--build-kit <buildKitName>", "Specify BuildKit");
program.option("-g,--global", "Use global environment", false);

7.2 Package Manager

Provides CRUD APIs for dependencies and performs version checks.

await context.pkgManager.add(plugin);
await context.pkgManager.remove(plugin);

7.3 Config System

Loads global and local configuration files, validates them, and offers cached getters for frequently used values.

const imflowConfig = await Config.build(cookedOptions);

7.4 Commander Command Module

Registers built‑in commands ( plugin, buildkit) with sub‑commands ( list, add, delete, switch). Handles duplicate command registration across plugins.

public registerCommand(command: string): Commander {
  const subCommand = command.split(" ")[0];
  if (this.commandMap.has(subCommand)) {
    // create a temporary commander to avoid conflict
    const tempProgram = new Commander();
    return tempProgram.command(command);
  }
  this.commandMap.set(subCommand, this.activePlugin);
  return this.cli.command(command);
}

7.5 Plugin System

Loads plugins according to the active BuildKit and configuration:

Business‑bound plugins (specific to a BuildKit).

Generic IMFLOW plugins.

FEFLOW plugins (converted to Commander commands).

During loading, the system creates a context that supplies APIs for plugins to interact with CORE.

In a global environment, the active BuildKit, its installed plugins, and all generic plugins are loaded; in a project environment, the project’s BuildKit, declared plugins, and generic plugins are loaded.

7.6 Market Plugin / Kit Ecosystem

Plugins are declared in the global configuration under each BuildKit. Example configuration:

{
  "buildKits": [
    {"name": "@tencent/imflow-buildkit-web", "installed": true, "plugins": ["@tencent/imflow-plugin-react-template", "@tencent/imflow-plugin-hulk-template"]},
    {"name": "@tencent/imflow-buildkit-scf", "installed": false, "plugins": []}
  ],
  "plugins": ["@tencent/feflow-plugin-codecc", "@tencent/imflow-plugin-cache-cors"],
  "activeBuildKit": "@tencent/imflow-buildkit-web"
}

8. Key Mechanisms

8.1 Config Initialization

When the user runs a create command, the system prompts to select a BuildKit before loading the configuration, ensuring the correct workflow is set up.

static async build(options) {
  if (isCreating(options.cliArgs)) {
    const inquirer = require("inquirer");
    const res = await inquirer.prompt({type: "list", name: "activeBuildKit", message: "Select project type", choices: this.staticGetBuildKits()});
    options.buildKit = res.activeBuildKit;
    options.global = true;
  }
  return new Config(options);
}

8.2 Plugin Loading

Business plugins declare a buildKitWhiteList static property. During installation, the system updates the global configuration to associate the plugin with each supported BuildKit, ensuring future compatibility.

if (buildKitWhiteList) {
  buildKitWhiteList.forEach(whiteBuildKit => {
    let declared = false;
    buildKits.forEach(kit => {
      if (kit.name === whiteBuildKit) {
        declared = true;
        kit.plugins.push(plugin);
      }
    });
    if (!declared) {
      buildKits.push({name: whiteBuildKit, plugins: [plugin], installed: false});
    }
  });
  config.setGlobalConfig("buildKits", buildKits);
}

8.3 BuildKit Installation

Installation simply toggles the installed flag or adds a new entry if the BuildKit is not yet present.

9. Results and Validation

9.1 Startup Time

After refactoring, startup times dropped dramatically:

Tool

Before (avg)

After (avg)

IMF

4.9 s

0.8 s

IMFS

6 s

3.2 s

9.2 Goal Completion

Decoupled core from business code – ✅

Plugin‑based build kits – ✅

Lightweight kits (sub‑1 s target) – ⌛ (SCF kit pending)

Unified configuration & dependency management – ✅

Standardized API exposure – ✅

FEFlow plugin compatibility – ✅

Backward compatibility – ✅

9.3 Beta Features

Sorted help output with source annotation.

BuildKit commands ( list, add, delete, switch) with interactive prompts.

Plugin commands ( list, add, delete) work globally and per‑project. create now asks for the desired BuildKit before initializing.

FEFlow plugins (e.g., @tencent/feflow-plugin-codecc) load seamlessly.

10. Conclusion

The redesign turned IMFLOW from a monolithic, hard‑to‑maintain tool into a modular, extensible platform. By introducing a lightweight CORE, plug‑in‑based BuildKits, and a unified configuration system, the team achieved significant performance gains, improved developer experience, and opened the door for community‑driven extensions.