A pnpm only monorepo with nine examples, an ssr deploy it does not own, and a 5 to 10 times speed claim

The preinstall hook rejects npm before anything installs

The first line of defence in package.json is a hook, not a doc:

"preinstall": "npx only-allow pnpm",
"bootstrap": "pnpm i && pnpm build",
"lint": "oxfmt --check .",
"release": "esno scripts/release.ts",

The root package is also marked private, so it is a workspace rather than something an npm install can pull in. Every other script follows from the workspace layout: dev and build both run across the packages directory with a filter, using --stream and, for dev, --parallel. Testing is Playwright at the top level, with headed and ui variants, and a playwright.config.ts sits next to the workspace file and lockfile.

One naming detail is worth flagging. The script called lint runs oxfmt in check mode and the fix variant runs oxfmt in write mode, so lint and format are the same tool here, and oxfmt is a formatter. Among the visible scripts there is no type check entry, so the build entries delegate that to the workspace packages instead. What the repository carries for its own tooling is a .husky directory, a .vscode directory and three TypeScript configs named tsconfig.json, tsconfig.cjs.json and tsconfig.esm.json, for the common, cjs and esm builds.

Example scripts start the inner app with npm

Every example entry point follows the same three part shape. It sets an environment variable naming the example, runs a prelink script, changes into the example directory, and then hands over to a package manager:

"example:nestjs:react18:prod": "EXAMPLE=nestjs-react18-ssr esno scripts/prelink.ts && cd example/nestjs-react18-ssr && npm run prod",
"example:midway:react:vite": "EXAMPLE=midway-react-ssr esno scripts/prelink.ts && cd example/midway-react-ssr && npm run start:vite",

So the outer repository refuses npm through its preinstall hook, while the example applications it starts are driven with npm run prod and npm start. The environment variable plus prelink step is what ties the workspace packages to that one example, and the vite variant is a separate script rather than a flag, so the build tool choice is baked into the script name.

The visible set covers midway-react, midway-react18, midway-vue, midway-vue3, nestjs-react, nestjs-react18, nestjs-vue and nestjs-vue3, in dev, prod and vite flavours. Scripts for cleaning and syncing go through node scripts/scripts.js with a --clean or --sync argument, and minification through esno scripts/minify.ts.

Nine example directories, four Midway and five Nest.js

The example directory holds nine applications: midway-react-ssr, midway-react18-ssr, midway-vue-ssr and midway-vue3-ssr under Midway.js, and nestjs-react-ssr, nestjs-react18-ssr, nestjs-vue-ssr, nestjs-vue3-ssr and nestjs-vue3-ssr-pinia under Nest.js. The split is what the documentation means when it calls the official default example an integration sample for two popular Node.js frameworks. The framework itself is stated not to be coupled to any Node.js framework, so the two names describe what is demonstrated rather than what is required.

The one deployment path named in the documentation belongs to one of those two. With Midway.js as the server framework, a built in ssr deploy command sends the application to Alibaba Cloud or Tencent Cloud in one click. No such command appears among the scripts in this repository, where the entries cover build, dev, lint, e2e, release and publish instead, which places that deploy step on the Midway.js side of the boundary rather than here.

One example carries a second axis: nestjs-vue3-ssr-pinia, matching the documentation's note that pinia is supported as the data management solution in Vue3 SSR.

The 5 to 10 times build claim arrives without a method

The version 7 announcement states that the release has been tested to improve build speed by 5 to 10 times, and that dependency size is reduced by two thirds when Rspack or Rolldown-Vite is the scenario. No machine, no processor, no project size, no baseline version and no measurement procedure accompany either number, and the dependency figure is explicitly conditional while the speed figure is not.

The other version 7 promises are framed the same way: progressive upgrade with almost no breaking changes, so v6 projects can move across smoothly; support for Rspack, Rolldown-Vite and Webpack; support for any frontend framework combined with any build tool; and a new dependency design that needs fewer packages at initialization. The upgrade guide and the version 7 feature page live in the documentation site rather than in this repository, so the detail behind those sentences is not something the code here can confirm.

Initialization is the one instruction given as a command, and it prompts for a v7 or a v6 template:

$ npm init ssr-app@latest my-ssr-project

The project itself evolved from egg-react-ssr and from a v4 line described as midway-faas plus React server side rendering, and the current line reorganised that into plugins so that any server framework can pair with any frontend framework.

Automatic degradation moves a server side failure into the browser

Rendering degradation is listed as a framework level capability: when server side rendering fails, the framework degrades to client side rendering by itself. That is a real convenience for a page that would otherwise be blank, and it also decides where a fault becomes visible. A component that throws only on the server produces a working page that renders in the browser instead, so the symptom a user or a reporter sees is a slower first paint or a flash of unstyled content rather than an error.

That makes the boundary between the two rendering modes worth naming deliberately in an application: anything that differs between the server pass and the browser pass, including data that only exists in one of them, is exactly what this fallback hides. The documentation offers the capability as a reason to choose the framework and does not describe a switch for turning it off or a way to surface the failure in development.

The surrounding claim in the same list is that this framework has the clearest rendering logic and application build logic among similar frameworks. It is a comparison without a criterion attached, and it sits in the same bullet list as the degradation feature, so it reads as positioning rather than as something the repository measures.

The customer table links three entries to nothing

The section listing who uses the project is a raw HTML table of Chinese company names, and a good part of it is placeholder markup. Several anchors carry href="#" with no destination at all, including the entries for WeChat's public platform, Tencent Sports and QQ membership. Other anchors use target="_bvlank" instead of target="_blank", so those links open a target that the browser treats as a new window name rather than a new tab, a one character typo repeated across several cells. A few anchors open with an empty body and close after the name, leaving an image placeholder where a logo should be.

The links that do resolve point at consumer properties: youku.com, wecard.qq.com, syzs.qq.com, a Tencent Video path, niuniuda.com, gszq.com, m.isle.org.cn and a b2bwings.com storefront. The two entries that document the framework's own deployment story are plain HTTP: http://ssr-fc.com/ labelled as the Alibaba Cloud sample and http://tx.ssr-fc.com/ labelled as the Tencent Cloud sample, which is also the scheme used for the project homepage, http://doc.ssr-fc.com/.

No tagged releases, and versioning happens in a script

There are no GitHub releases for this repository, and the numbers a user would look for are produced by two scripts instead: release runs esno scripts/release.ts, and ci-publish runs esno scripts/publishCI.ts. Nothing in the visible scripts prints or pins a version, and the root package carries no version field at all, only the name ssr, the private flag, the homepage, the issue tracker, the MIT license and the author.

That private flag is the reason the install instruction does not use this repository's own name. A user starts a project with the create-ssr-app generator, which npm init ssr-app@latest resolves on its own, while a contributor clones the monorepo and runs bootstrap, which is pnpm i followed by pnpm build across the workspace. The two paths share nothing but the framework packages under packages/.

The default branch is dev rather than main, and its most recent push is dated 2026-08-17. So a reader tracking versions by tag finds nothing to track, and a reader tracking the branch finds movement with no release note attached to it in the repository.

React 19 is in the introduction and missing from the description

The repository description names React17, React18, Vue2 and Vue3. The introduction adds React 19, giving React 17, 18 and 19 alongside Vue 2 and Vue 3 as the supported frontend frameworks for server side rendering, and the tooling line covers Vite, Webpack and Rspack for startup, build and hot reload speed. The same passage then widens the claim to any frontend framework combined with any build tool, which the table of examples does not demonstrate: nine directories, all React or Vue, all Nest.js or Midway.js, all using the two named build tool families.

The documentation site is itself built with the framework and deployed to Alibaba Cloud Serverless, and it hosts both the introduction and the version 7 upgrade guide, at paths that include a dollar sign in the URL, /docs/features$v7. The English README links to a Chinese one at README_Zh.md, and the file is otherwise a mixture of English prose, badge markup and that Chinese customer table, which is why the logo names in it are the only part that needs a translation.

For a reader deciding whether this fits, the example directory is the honest part of the evidence, because those nine applications are combinations someone actually kept working, while the framework support list is a statement about intent.

Editorial conclusion

ssr fits a team that already has a Node.js backend and wants server side rendering without assembling the pieces itself, and the nine example directories are the fastest way to judge whether the combination fits. Before installing anything, note that the repository root is private and marked private on purpose, so what npm publishes is the individual packages, while a checkout has to be installed with pnpm because the preinstall hook runs only-allow pnpm. Two claims deserve checking before you rely on them. The 5 to 10 times build speed improvement and the two thirds smaller dependency size are stated without a machine, a project, or a baseline, and the dependency figure is scoped to Rspack or Rolldown-Vite. And the one click ssr deploy belongs to the Midway.js path rather than to scripts in this repository. There are no tagged releases, and the dev branch was last pushed on 2026-08-17.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. zhangyuang/ssr on GitHub