f2e-spec: Alibaba front-end guidelines and the tooling that enforces them

A guideline set and a toolchain in one repository

The alibaba/f2e-spec repository is two projects sharing one tree. The first is a body of documentation, written in Chinese, describing coding rules for JavaScript, TypeScript, React, Node.js, CSS, and HTML, plus engineering rules for Git, general documentation writing, and changelog entries. The second is a set of executable rule packs published to npm, one per linter, plus a wrapper package called F2ELint that installs and runs them.

The stated purpose is collaboration cost. The README describes the specification as widely used inside the Alibaba economy, with the aim of unifying coding style, popularising best practices, and checking for code defects, so that teams spend less time on coordination and get more maintainable and stable front-end projects. That framing explains a design choice that would otherwise look odd for an open source project: the rules come from a large organisation's internal habits rather than from a community vote, and the documentation and the tooling are kept in step by hand.

For an engineer outside that organisation, the appeal is concrete. You get a curated opinionated baseline for a front-end stack, in a form you can adopt wholesale or cherry-pick, instead of assembling rules from several guides by hand. The homepage for the project is a documentation site at alibaba.github.io/f2e-spec, and the whole thing is published under MPL-2.0, a file-level copyleft licence that suits documentation and configuration content.

Seven guideline documents mapped to seven linters

The documentation is organised as two families. The coding guidelines live under docs/coding and cover javascript.md, typescript.md, react.md, node.md, css.md, and html.md. The engineering guidelines live under docs/engineering and cover git.md, writing.md, and changelog.md. Each of those documents has a matching executable artefact, and the mapping is explicit:

eslint-config-ali
stylelint-config-ali
commitlint-config-ali
markdownlint-config-ali

The JavaScript, TypeScript, React, and Node.js guidelines all map onto ESLint through the same eslint-config-ali pack, the CSS guideline maps to stylelint through stylelint-config-ali, the Git guideline maps to commitlint through commitlint-config-ali, and the documentation guideline maps to markdownlint through markdownlint-config-ali. Four underlying linters, four published config packages, and nine written documents, so the count of artefacts does not map one to one onto the count of guidelines.

What this structure buys is a single consistent source of truth per tool. A JavaScript rule and the corresponding TypeScript rule are not two separate packages that can drift; they are rules in one ESLint config that reads well in both languages. The trade-off is that a project that only wants the CSS rules cannot take a slice of ESLint at the same granularity, which is one reason the wrapper package exists.

F2ELint exists because the individual packs add up

The README is blunt about the problem the wrapper solves. The linters and rule packs are numerous and scattered, installing all of them would add more than ten dependencies to a project, and both the initial setup and later upgrades would be costly. F2ELint is the npm package built to answer that: it hides the dependencies and configuration details behind a simple CLI and a Node.js API, so a project can connect, scan, fix, and upgrade the specification in one step, and so a project can configure a git commit gate.

That phrasing matters for what you can expect from the tool. The value is not new lint rules. Every check F2ELint performs comes from eslint-config-ali, stylelint-config-ali, commitlint-config-ali, or markdownlint-config-ali, and from ESLint, stylelint with stylelint-scss, commitlint with conventional-changelog-conventionalcommits, and markdownlint. F2ELint is a delivery and orchestration layer, not a rule author. If a rule is wrong for your project, you will not fix it in F2ELint, you will override it in your own ESLint configuration.

You are also free to ignore the wrapper. The README says you can use F2ELint to connect the full set of guideline linters, or install the individual config packages and linters as needed. The underlying linters are mainstream ones, so a team with strong opinions about its own setup can adopt only the parts that fit.

Git commit messages are inside the scope

Most style guide projects stop at source code. This one treats the commit message as a reviewable artefact, and it does so through a separate linter and a separate rule pack. The Git guideline under docs/engineering/git.md is enforced by commitlint through commitlint-config-ali, and the commit hook is part of the intended setup rather than an optional extra.

The repository itself is configured as a working example. The root package.json extends @commitlint/config-conventional for its own commit messages, which is the same Conventional Commits family that the F2ELint wrapper configures for consumer projects. The cited sources list makes the lineage explicit, including Semantic Versioning 2.0.0, Conventional Commits 1.0.0, and Conventional Changelog.

There is a second, quieter rule channel in the same package.json. A lint-staged configuration runs eslint --fix on code files and prettier --write on a wider set of extensions, and husky is wired up as the git hook runner in the prepare script. Prettier is configured with the separately published prettier-config-ali package, so formatting is treated as part of the specification too, even though the table of rules does not list it as one of the four linters.

{
  "commitlint": {
    "extends": ["@commitlint/config-conventional"]
  }
}

This is the part of the project most likely to cause friction in an outside team, because commit message format is a workflow-wide decision rather than a per-file one, and it is enforced before anyone reviews the diff.

A documentation site built with Rive

The docs are not a folder of Markdown files served raw. The root package.json configures rive with a doc block that sets the title to Alibaba Front-end Specification, the basename to /f2e-spec/, and the root to docs, and the scripts wrap it: rive build for the production build, rive build --watch, and rive start for local development. Deployment uses gh-pages against a build directory, which is what publishes the site behind the alibaba.github.io address.

The rest of the repository is a pnpm workspace with a packages/ directory holding the published rule packs, a pnpm-workspace.yaml, and an eslint.config.mjs at the root using the flat config format. Tests run on Vitest, with both vitest.config.ts and vitest.workspace.ts present and a vitest --ui mode for the browser interface. Formatting is Prettier, linting is ESLint, and the editor configuration is a committed .editorconfig alongside a .vscode directory. There is also a .markdownlint.json, which is the project applying its own documentation rules to its own documentation.

The most recent published artefacts give a sense of the release rhythm. stylelint-config-ali reached 3.0.0 on 2026-04-01, and f2elint moved from 6.3.4 on 2025-12-19 to 6.3.5 on 2026-02-02. The last push to the repository was on 2026-05-06, so the documentation and the packages move on a slower cadence than a typical application repository.

Where the guidance is thinner than the tooling

Two limits deserve a straight answer before anyone adopts this.

The first is language and reach. The guideline documents are written in Chinese, and the project describes itself as a specification used inside the Alibaba economy, with contributor lists naming the people who wrote and reviewed each document. For a team outside that context, the value depends on reading Chinese or on finding the underlying rules in the npm packages, which are the machine-readable half of the project. The rules themselves are not Alibaba-specific in the sense of encoding internal APIs, but the way they are explained, the examples, and the priorities behind them come from one organisation's practice. A team whose taste differs will spend time turning rules off, and the project does not document a supported way to negotiate that beyond ordinary ESLint override mechanics.

The second is the gap between a guideline and a rule. A written document can recommend a practice that no linter checks, and a rule pack can enforce something the document never mentions. The mapping table in the README links each guideline to its linter, which makes the pairing easy to check, but it does not claim one rule per documented sentence. If you want to know what is actually enforced, the npm packages are the authority, not the prose.

A third, smaller caveat: the specification is opinionated about React, TypeScript, and the rest in the way a large company is opinionated, and adopting all of it wholesale is a bigger decision than installing four rule packs. The projects inside the Alibaba economy are its target environment, and the rules carry that assumption.

F2ELint versus wiring the four linters yourself

The realistic alternative to the wrapper is to skip it. Install eslint-config-ali, stylelint-config-ali, commitlint-config-ali, and markdownlint-config-ali directly, alongside ESLint, stylelint, commitlint, and markdownlint, and write your own flat config and your own husky hooks.

The difference in approach is exactly what the README claims. Doing it yourself means you own the dependency tree and you can drop the parts you do not want, such as taking the CSS rules without the commit message gate, and you avoid a wrapper dependency in the tree. The cost is that the initial setup, and then every version upgrade of the rule packs, is your problem, which is the pain F2ELint was built to remove. The wrapper earns its place exactly when the team wants the full set, wants the commit gate, and does not want to track four configs and four linters by hand.

A third path is to treat the documents as inspiration and use a different community standard for the mechanical checks. That gives you an off-the-shelf setup and independent maintenance, at the price of the specific, opinionated rules this project exists to provide. The README itself points at the Airbnb Style Guide, the Google Style Guide, and the Code Guide by @mdo among the sources its documents reference, so the rules here are best read as a curated selection rather than a unique invention.

Editorial conclusion

Adopt F2ELint if you want one command that wires the whole Alibaba rule set into a project, and adopt the docs on their own if you would rather pick rules piece by piece. Do not adopt either if your team expects an international tool with an English rule reference. Verify first that the rules in eslint-config-ali match your own standards, since the docs and the packs can drift apart.

Frequently asked questions

Official sources

1. alibaba/f2e-spec on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases