Feflow: Tencent's front-end CLI, and a release line that stopped in 2023

What the tool is for

Feflow is described as a tool that aims to improve the front-end engineer workflow and standard, powered by TypeScript, and the README calls it an engineering solution of Tencent's open source front-end field, committed to improving development efficiency and specification.

Read that carefully, because it narrows what the project is. This is not a general developer toolbox, it is an attempt to standardise how a group of engineers start a project, add a plugin, configure a tool and stay consistent with each other. The value of such a tool is organisational: the workflows it encodes are the ones the organisation has already agreed on, and the plugin system lets a group extend them without waiting for the core tool to grow.

The delivery is a global npm install, and the package is `@feflow/cli`. There is a Chinese README beside the English one, `README.CN.md`, and a Chinese contributing guide in `CONTRIBUTING.CN.md`, which is a reminder that this is a project with contributors in two working languages.

The repository is a monorepo. The root `package.json` declares npm workspaces over `packages/*`, and the tooling is Lerna, with a `lerna.json` at the root. The TypeScript configuration is split three ways, a `tsconfig.json` for the editor and the general build, a `tsconfig.build.json` for the compiled output and a `tsconfig.eslint.json` for the linter, which is the standard arrangement for a TypeScript monorepo where the linter needs to see the same program the compiler does.

The licence in the README is MIT, with the text in `LICENSE.txt`, while the repository metadata does not classify the licence under a standard name, so the file in the repository is the text to rely on.

Installing it, and the six native commands

The installation is a global npm install, and the README is direct about it.

npm install @feflow/cli -g

The command set is described as three kinds, and the first kind is the native commands, which are the ones the tool ships with:

fef config
fef help
fef info
fef install
fef uninstall
fef list

That list is worth reading for what it implies. `fef config` is the tool's own configuration, `fef info` reports on the environment, and `fef install`, `fef uninstall` and `fef list` are a package manager for the plugins. So the tool has a configuration, knows about the machine it runs on, and can install and remove the pieces that do the actual work.

The two remaining kinds of command are the devkit and the plugin, and the README is explicit that you can write a Feflow devkit or a plugin to extend commands. That is the whole extension model, and it is what turns Feflow from a script into a platform: a team writes a devkit that exposes its own commands, and those commands sit alongside the native ones in the same CLI.

The documentation is in two places, the GitHub wiki and a website, and the README links both to the same place, so the wiki is the reference. There is a changelog section in the README that says the project adheres to Semantic Versioning, and that every release along with the migration instructions is documented on the GitHub Releases page, which is the page to read before an upgrade rather than the commit log.

The monorepo builds the CLI last, and checks the npm version first

The root `package.json` of the repository is more interesting than a typical one, because two of the scripts encode process rules.

The build script is:

  "scripts": {
    "build": "lerna run build --ignore @feflow/cli && lerna run build --scope @feflow/cli",
    "test": "lerna run test",
    "release": "lerna publish from-git --dist-tag $DIST_TAG --yes",
    "check-npm-version": "node ./scripts/check-npm-version.js",
    "preinstall": "npm run check-npm-version",
    "preversion": "lerna clean -y && lerna bootstrap"
  },

The build runs in two passes on purpose. The first pass builds everything except the CLI package, and the second builds the CLI itself, which means the CLI is compiled against the freshly built artefacts of the packages it depends on rather than against whatever happens to be in the registry. A tool whose plugins are the products and whose CLI is the shell around them cannot afford a version skew between the two.

The release script publishes from git, with the distribution tag passed in, so a release is cut from a tagged commit rather than from whatever is in the working tree. And the `preinstall` script runs a version check before anything is installed, which is a small but unusual guard: it makes the tool refuse to install in an environment whose npm version is not one the project supports, at the point where the damage would happen, rather than later with a confusing error.

The `preversion` script cleans and bootstraps, so a version bump starts from a known state. The bootstrap script is `lerna bootstrap --no-ci`, and the presence of a separate `bootstrap` target next to npm workspaces shows the project was in the middle of the move from one to the other, since the workspaces declaration and the Lerna bootstrap command do the same job in two different ways.

Mocha, coverage, commitlint and an internal eslint config

The development dependencies describe the working practices of the team that built this, and they are worth a pass.

The test stack is Mocha with chai and sinon-chai, run through `ts-mocha` so the tests are TypeScript, with `nyc` for coverage, `mochawesome` for the HTML report and `mocha-junit-reporter` for a report a CI system can read. Two report mechanisms side by side is normal for a project whose CI and whose developers want different things from the same run.

The linting is ESLint with `eslint-config-tencent`, the organisation's own shared configuration, plus plugins for mocha, chai and prettier, and a separate `tsconfig.eslint.json` so the linter resolves the same types the compiler does. The formatting is Prettier, and `lint-staged` runs `eslint --fix` over the JavaScript and TypeScript files that are staged.

The commit discipline is the conventional commits format. `@commitlint/cli` with `config-conventional`, `commitizen` with `cz-conventional-changelog` for the interactive prompt, and `husky` for the git hooks, with a `commitlint.config.js` at the root. The commit hook is not decoration either, because the release script publishes from git and generates the changelog from the commit messages.

There is also a `.nvmrc`, a `.travis.yml` for the continuous integration, an `.eslintignore` and an `.editorconfig`. The dates in that dependency list are a clue about the project, since the versions are from the 2021 to 2022 range, which is consistent with a repository whose last release was in 2023.

A release line that stopped while the branch kept moving

The release history is short and the gap at the end of it is the most important fact in this repository for anybody considering it.

The recent releases are v0.27.1 from 2023-06-30, v0.27.0 from 2023-06-18 and v0.26.3 from 2023-03-29. The last push to the repository was on 2026-04-21, and the default branch is `master`.

So the branch has received commits into 2026, three years after the last published version. There is no release to install for the current state of the code, and the version numbers on the npm package stop at 0.27.

That is not necessarily a sign of a dead project. A tool like this is installed once into a company and then lives in the internal registry, and a version that is not republished to the public npm may still be shipped internally, and the branch may be maintained for that purpose. But the public evidence says what it says, and a reader has to take the releases page as the source of truth for what exists and the branch as a separate thing.

The README's own contribution link points at a `next` branch rather than `master`, which is another detail worth noting. The link to the contributing guide is `https://github.com/Tencent/feflow/blob/next/.github/CONTRIBUTING.md`, so the development happens on a branch called `next`, and `master` is the branch the README badges and the build status refer to.

The version check script in the root package is the other clue, since a tool that refuses to install on an unsupported npm version is a tool with an opinion about the environment, and a tool with opinions needs its maintainers to keep the opinions current.

Where Feflow is the wrong tool

The limits are mostly about scale, and they follow from the fact that the value of the tool is in its ecosystem rather than in its six native commands.

The first is the plugin economy. The native commands configure the tool, report on the environment and install plugins. If your workflow needs a plugin, and the plugin does not exist, the tool does nothing for you that a shell function would not do. So the adoption question is not whether Feflow is good, it is whether the plugins your team needs are published, and that is a question about a registry rather than about a codebase.

The second is the version question, which the previous section makes concrete. The last public release is from 2023, and a team that adopts it today is adopting a two year old package. For an internal tool that is often fine, because the team can run the branch or the package from the internal registry. For a tool that is going into a public project or a shared open source repository, it is a problem, because the guarantees that the public version carries are the guarantees of 2023.

The third is the documentation location. The reference is a GitHub wiki, which was normal in 2021 and is now a liability, because a wiki is where documentation goes to be correct and out of date at the same time, and a wiki is not versioned with the code that it describes.

The alternative, for a small team, is to put the two or three scripts that matter into the repository and call them with npm scripts, which is what most teams do anyway, and the difference in approach is that Feflow is a distribution mechanism for shared workflows, with a plugin model and a CLI as the contract, and the alternative is a repository that happens to contain the scripts. The first scales across a large organisation with many teams, and the second scales across a small one with a single repository, and picking the wrong one means maintaining scaffolding that nothing else uses.

Editorial conclusion

Feflow fits a front-end team inside a large organisation that has standardised its project scaffolding and wants one tool to carry that standard, and that is willing to maintain plugins of its own. It is the wrong choice for a small team, because a plugin-oriented CLI earns its keep through the shared plugin set rather than through the native commands, and the wrong choice for a project that needs the current release, because the last published version is v0.27.1 from 2023-06-30. Before adopting it, check whether the plugins your workflow depends on are still published, read the Releases page for the migration notes on the version you would start from, and decide whether the alternative, a couple of scripts in the repository, would serve your team better.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Tencent/feflow on GitHub