The theme's lint script backgrounds half of itself, and its Project Status section is empty

Five performance numbers with no baseline anywhere on the page

The rewrite section ends with five percentages, and they are the only measurements in the readme.

The development server's cold start is said to be eighty percent faster. Build memory usage is said to be seventy-five percent lower. Build time is said to be eighty-five percent lower. Output size is said to be forty-five percent smaller. Web page performance is said to be sixty percent better.

Every one of them is relative to the previous major version, and not one has an absolute figure behind it, a name for the project measured, a hardware description, a run count or a link to a benchmark. There is also no statement of which metric is being reduced: build time could be wall clock on a warm dependency cache or a cold one, and those differ by an order of magnitude.

Eighty-five percent is the number that deserves most suspicion. A build-time reduction that large usually means something stopped being built, or that the measurement excludes the part that got slower. The output-size figure points the same way: a smaller bundle is a good thing until you notice that the same paragraph lists what was removed.

What the page does not say is which features the rewrite dropped. For a theme, that is the trade that matters, and it is the one a reader cannot reconstruct from these numbers.

It is four themes published under one name, from a private root package

The repository description says a theme. The workspace configuration says otherwise.

The root package is named for the project with a root suffix, is marked private, and declares three workspace globs: one for demos, one for the documentation, one for the packages. Under the demos there are separate directories for a docs theme and a blog theme, plus directories for shared demo components and for two markdown-enhancement and gallery fixtures.

So the source tree builds several themes side by side and the one on the package registry is a single package inside it. The root package exists to hold the workspace definition and the shared scripts, and it is never published.

That arrangement is normal for a multi-package repository and it has one consequence for a user. When you install the theme you get one package, and the documentation site, the demos and the other themes are not part of what you installed. It also means the repository's size is a poor proxy for the size of the product.

The version-control layer reflects the same arrangement twice over. There is both a package-manager workspace file and a release-tool configuration file, and both tools are in the dependency list. Dependency resolution comes from the package manager; versioning and publishing come from the release tool. That combination is the current answer for a multi-package repository that wants independent versions with a shared workspace layout.

The newest releases are candidates published seconds apart

Read the three most recent release names and their timestamps together.

They are all release candidates for the same major version. One is candidate one hundred and seven, one is one hundred and eight, and one is one hundred and ten, and the last two of those were published thirty and twenty seconds apart. Candidate one hundred and nine does not appear in the list at all.

So the release process here is automated to the point where a single run can publish several candidates in a minute, and some of those numbers get used and some do not. That is normal for a tool that publishes candidates continuously so that a regression can be bisected, and it is a good practice. It is also worth knowing before you install one, because the newest thing on the registry is not a stable release.

Which brings up the page's own answer to that question. There is a heading called Project Status, and there is nothing under it. The next heading is Contributors.

So for a project whose major version is out in candidates, whose readme describes that major version in the present tense, and whose repository description calls itself a theme with a fixed article, the one place that would say whether version 2 is stable is empty.

That is the section a reader checks first when they are deciding whether to pin a version, and it is the section with nothing in it.

The lint script runs its two halves concurrently, so half of it cannot fail the command

There is one line in the package manifest that is worth reading twice.

The lint script runs the JavaScript linter with autofix, and then, separated by an ampersand rather than an ampersand-and-ampersand, it runs the formatter and the style linter with autofix in the background. The check variant of the same script has the same shape.

In shell, a single ampersand backgrounds the left-hand side and does not wait for it. So the command returns when the first half finishes, and the style check runs concurrently, detached. If the style linter finds an error, the exit code that the caller sees is the first half's, and a style failure does not fail the lint.

The fix is one character, changing the separator to the conditional form, and it is the kind of thing that survives because the linter almost always passes and the style linter almost always passes, so nobody notices the third state.

It sits in a repository with three other linters, a shared lint configuration package, a commit-message verifier in a git hook, and a staged-file runner. The tooling density here is genuinely high. That makes the concurrency bug more surprising, not less, because in a repository with this much checking you would reasonably assume a style error fails the command.

There is one more exemption worth noting. The readme opens by disabling the markdown linter, and restores it several lines later, around the block of badges. So the file that carries the project's own quality signal is the one file exempt from one of its linters.

A shared configuration package is versioned zero point zero point four

Look at the pinned versions in the development dependencies and one of them does not look like the others.

Nearly everything is pinned to an exact version, no carets: the Node type definitions at a specific patch, the release tool at a specific minor, the linter at a specific version, the formatter at a specific version, the test coverage provider at a specific version. That is a deliberate choice and it makes a build reproducible by declaration.

Among them sits a shared TypeScript configuration package at version zero point zero point four, and beside it a shared lint configuration package at a zero minor. Those two are the foundation every package in the workspace compiles and lints against, and they are pre-release by their own numbering.

So a repository that pins everything else to an exact version has two dependencies that can change underneath it without a version bump being visible in the lockfile, because the version number does not move when the package does.

The same pattern shows up in the scripts. The dependency-update checker runs a package-update tool through a one-off runner with no version, which means the tool that tells you what to upgrade is itself unpinned.

None of this is a crisis. It is a coherent, well-run monorepo with two small seams in it, and the seams are both in the tooling rather than in the theme.

Release publishes without confirmation and then syncs a mirror

The release target is one line, and it is a chain of five steps.

pnpm clean && pnpm bundle && pnpm release:version && pnpm release:publish && pnpm release:sync

Clean, then build every package with a production environment flag and streaming output, then version, then publish, then sync. The publish step is the release tool's publish command with a from-package mode and a flag that answers yes, so nothing prompts.

The build step is the interesting one. Setting the production environment flag in front of a recursive build means each package's own build script runs with it set, rather than the orchestrator deciding what each package needs. It is simple and it works, and it is the kind of global flag that quietly changes behaviour in any package that branches on it.

The last step is the one that tells you where this is developed. It runs a script whose job is to synchronise the published packages to a package mirror. That is the standard arrangement for a project published from one side of the world and consumed from another, and combined with the Open Collective link and the Telegram group and the Chinese and Russian documentation in the repository, the picture is consistent: a project maintained for a global audience with a regional mirror as part of its release path.

The mirror script is the only step of the five that is project-specific rather than tool-specific, and it is the one a new maintainer would need to understand first.

Editorial conclusion

The rewrite claim is the thing to interrogate. Moving a documentation theme to the current major version of its framework is a large job with real gains, but five round percentages without an absolute figure or a project name are marketing copy rather than a benchmark, and a forty-five percent output-size reduction can just as easily mean features were dropped. Read the migration guide instead. And check which release channel you are on, because the readme does not say whether the current major version is out.

Frequently asked questions

Official sources

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