vuepress/core: release candidate 31, two commit conventions, one serial build

The core packages live here and everything else lives in two other repositories

The README is short and its second half is a routing table. This repository holds the core packages of VuePress. Plugins, themes and tools belong to `vuepress/ecosystem`, and the source of the documentation site belongs to `vuepress/docs`. So the three things a VuePress user touches, the generator, the extensions and the docs, are three repositories, and only one of them is this one. The shape of that core repository is a pnpm workspace: a `pnpm-workspace.yaml`, a committed `pnpm-lock.yaml`, a `packages/` directory holding the actual packages, and a root manifest named `@vuepress/monorepo` that is marked private and typed as an ES module. Nothing is published from the root; the publishable artefacts are the individual workspace packages, which is also why the build script iterates over the workspace rather than running one command.

The commit hook and the changelog generator parse commits with different presets

Two tools read commit messages in this repository and they disagree about the format. The hook side is commitlint, configured in `commitlint.config.ts` against `@commitlint/config-conventional`, with husky and lint-staged installing the hook on prepare. The changelog side is a different parser with a different preset:

"release:changelog": "conventional-changelog -p angular -i CHANGELOG.md -s"

The `angular` preset is the one conventional-changelog ships for Angular's history, which is stricter about the imperative mood and the scope syntax than the conventional preset the hook enforces. The command edits `CHANGELOG.md` in place and is silent otherwise. In practice the effect is that a commit message can pass the hook and still be parsed loosely by the generator, or be read differently by the two, and the changelog is only regenerated during a release, so the mismatch shows up at release time rather than at commit time.

Release candidate 31, and the newest push is two months past the last tag

The status line at the top of the README is a single line, `Status: Release Candidate`, and the manifest version is `2.0.0-rc.31`. The release record shows a run of candidates rather than a final: rc.31 published 2026-07-24, rc.30 on 2026-05-14 and rc.29 on 2026-05-08. The last push to the default branch is dated 2026-09-29, roughly two months after the newest candidate, which is the shape of a repository still taking changes against a pre final line rather than one that has stopped moving. For anyone arriving from the first major version, the README points at a migration guide on the documentation site, and the contribution guide is published in two languages, `CONTRIBUTING.md` and `CONTRIBUTING_zh.md`, as the entry point for the development workflow, coding standards and contribution process.

Formatting belongs to oxfmt, linting belongs to eslint, and the two never overlap

Three scripts split the work cleanly:

"format": "oxfmt",
"lint": "eslint . && oxfmt --check",
"lint:fix": "eslint --fix . && oxfmt"

Formatting is a separate program from linting, and the lint script only asks oxfmt whether the tree is already formatted. The eslint side uses the shared `@vuepress/eslint-config` together with `eslint-plugin-import-x`, and the formatter has its own shared package, `@vuepress/oxfmt-config`. TypeScript configuration is shared through a third, `@vuepress/tsconfig`. All three sit at the same `^8.2.1` version while the monorepo itself is at 2.0.0-rc.31, so the shared tooling is versioned on its own line and moves independently of the packages it configures. Type checking is separate again and goes through `vue-tsc --noEmit`, so a type error and a lint error arrive from different tools.

The release gate chains five commands and omits two suites

A release is a single chain. `release` runs `release:check` and then `release:version`, and the check half is:

"release:check": "pnpm clean && pnpm build && pnpm check-types && pnpm lint && pnpm test"

Five steps: clean, build, type check, lint, test. What `test` expands to is `test:unit` followed by `test:e2e`, unit tests under vitest and the end to end package run twice, once in a dev mode and once in a build mode. Two scripts sit outside that chain. `test:e2e:webpack` runs the same end to end package against a webpack flavoured build, and `test:unit:cov` reruns the unit suite with coverage, which is also the suite the Coveralls badge reports on. So a green `release:check` means the default bundler path passed, and says nothing about the webpack path or about coverage instrumentation.

Builds run one workspace at a time, and clean runs them all at once

The build script is deliberately serial:

"build": "pnpm -r --workspace-concurrency=1 --stream build",
"clean": "pnpm run --parallel --stream clean"

`--workspace-concurrency=1` means the packages build one after another, with output streamed, which is the setting to reach for when the build graph has ordering requirements or when a shared artifact is produced by one package and consumed by the next. The clean script does the opposite and runs every workspace's clean in parallel, streamed. Both keep the stream flag, so the terminal output is interleaved and ordered the same way in each case. The end to end targets filter a single workspace package by name, `pnpm --filter e2e`, which is how the dev and build variants reuse one package for both modes.

The version bump writes the changelog inside the publish commit

Version bumps are handled by bumpp, and the wiring is worth reading:

"release:version": "bumpp -r --execute=\"pnpm release:changelog\" --commit \"build: publish v%s\" --all"

The version is bumped across all packages, the changelog generation is handed to bumpp as a command to execute, and the resulting change is committed with a message built from a template where `%s` stands for the new version. So the changelog is regenerated after the version has moved and lands in the same commit that carries the version change, with a message of the form build: publish followed by the tag. Around that sit the remaining conventions: three separate tsconfig files, one for the base, one for the project and one for declaration output, a vitest config for unit tests, a `taze.config.js` for browser feature checks, a `.node-version` pinning the Node version, and a workspace catalog referenced as `catalog:vite` by the vite, tsdown and Istanbul coverage entries so those versions are pinned in one place.

Editorial conclusion

vuepress/core is the engine rather than the product a user installs, and it is worth reading for the tooling conventions alone: a serial workspace build, declaration output split from type checking, formatting delegated to oxfmt while eslint keeps the linting, and a release script that regenerates the changelog inside the version bump commit. Two things to check before depending on it directly. The project is still marked as a release candidate, at 2.0.0-rc.31, so pin an exact version and read the migration guide if you are coming from VuePress 1. And the release gate is narrower than it looks, since the webpack end to end variant and the coverage run are separate scripts that `pnpm release:check` does not include, which means a green release did not necessarily exercise either. For most teams the practical entry point is not this repository at all: plugins and themes live in a separate ecosystem repository and the documentation site has its own.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vuepress/core on GitHub