pvzg_site: the VuePress website and docs behind a Plants vs Zombies 2 remake
PvZ2 Gardendless Official Website | A rewritten Plants vs Zombies 2 PC port
At a glance
- What is it?
- Gzh0821/pvzg_site is the open source repository for the website of PvZ2 Gardendless, a Plants vs Zombies 2 rewrite built entirely with web technologies including the Cocos engine. The site itself is a VuePress 2 documentation project deployed with Wrangler, and it carries the downloads, guides, feedback module, and several data-checking scripts for the game.
- Who is it for?
- Adopt this repository if you are working on the PvZ2 Gardendless project and want to change the site, the guides, or the data checks alongside the game. Do not treat it as the game source, since the game lives in a separate repository and this one is only the site.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly Vue, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The repository is the site, not the game
The first thing to establish is what this repository actually contains, because the name is misleading. The README states that this is the open source repo of the website of PvZ2 Gardendless. The game itself is elsewhere: the source code for the game is in a separate game repository, and there is an online play build at play.pvzge.com.
What PvZ2 Gardendless is, according to the project description, is a rewritten Plants vs Zombies 2 built entirely using web technologies, including the Cocos engine. The site is the public face of that project. It hosts download links, game guides, and more, and it carries a feedback module where users can report bugs, leave comments, and make suggestions, in addition to the issues and discussions on the code repository.
The project is maintained under an author badge for Gaozih, and the repository is Apache 2.0 licensed with a LICENSE file at the root. The site itself is at pvzge.com, the default branch is main, and the last push to the repository was on 2026-10-16, so the site is actively worked on. Recent published versions are 0.15.0 from 2026-09-29, 0.14.0 from 2026-09-10, and 0.13.0 from 2026-08-14.
The primary language of the repository is Vue, and the top level entries reflect a documentation site rather than an application: a src/ directory, docs/, scripts/, a crowdin.yml for translations, a wrangler.jsonc for deployment configuration, tsconfig.json, d.ts, and pnpm-workspace.yaml with a pnpm lockfile.
A VuePress 2 documentation site on release candidates
The site is built with VuePress 2 and deployed to Cloudflare Workers through Wrangler, and the dependency versions are the interesting detail. The VuePress packages are all pinned at 2.0.0-rc versions, which means the documentation toolchain itself is on release candidates. The @vuepress/bundler-vite is at 2.0.0-rc.30, the helper at 2.0.0-rc.110, and the docsearch and redirect plugins at 2.0.0-rc.130, alongside the vuepress package at 2.0.0-rc.30 and the vuepress-theme-hope theme at 2.0.0-rc.107.
The theme choice, vuepress-theme-hope, is what gives the site its feature set, and the plugin list tells you what those features are: docsearch for search, redirect for moved pages, and a watermark plugin from the same family. The Vue core is at 3.5.34 and Vite at 6.4.2.
The runtime dependencies are the interface layer. Ant Design Vue at 4.2.6 and its icon package provide the component set, vue-i18n at 11.4.4 with the intlify unplugin handle translations, axios handles HTTP calls, qrcode at 1.5.4 generates the QR codes, and json5 is there to parse configuration that is not strict JSON.
The scripts in the manifest show the shape of the site workflow. The documentation commands are docs:build with vuepress-vite build src, docs:dev with vuepress-vite dev src, and a docs:clean-dev variant that adds the clean-cache flag. The deploy script is pnpm docs:build followed by wrangler deploy, and preview is the same build followed by wrangler dev, so a preview runs against a local Workers runtime rather than a plain static server. There is also docs:update-package, which uses pnpm dlx vp-update to refresh the VuePress packages.
The checking scripts, which are the real engineering here
The most interesting scripts in the manifest are the check and build ones, because they are not about the website at all. They are about the game's data.
check:almanac runs node scripts/check-almanac-pages.mjs, which validates the almanac pages. build:level-editor-objects runs node scripts/build-level-editor-board-objects.mjs and check:level-editor-objects runs the corresponding check, so there is a generator and a verifier for the objects that can be placed on a level editor board. check:level-editor-waves runs node scripts/check-level-editor-wave-roundtrip.mjs, which checks that wave definitions survive a round trip, meaning a wave can be written out and read back without losing information.
That last one is the pattern worth noticing. A round trip test is the right way to check serialisable game data, and it is the kind of check that catches a field that is written but never read, or read but never written, which is exactly the class of bug that appears when a level editor and a level format are maintained by different people over time.
The plant decoding tests are similar. test:plant-decoding runs node src/components/plant-decoding/solver.test.mjs followed by node src/components/plant-decoding/solver.stress.test.mjs, both inside the src/components directory rather than a separate test directory. The component therefore carries its own tests with it, and the presence of a separate stress test alongside the ordinary one suggests the solver has an input space where performance or pathological cases matter.
The important structural point is that these scripts are runnable on their own, with node and a file path, rather than through a test framework with a discovery mechanism. For a project where a maintainer wants to check a specific data file after an edit, that is the faster loop.
Deployment through Wrangler and CDN sponsorship
Deployment goes through Wrangler, with the configuration in wrangler.jsonc at the repository root. The JSONC extension matters a little, since it permits comments in the configuration, which is useful for a file that has environment-specific settings and notes.
The build-then-deploy split in the scripts means the same bundle is used for production and for the local preview, so wrangler dev is a faithful rehearsal of what gets deployed. The consequence is that anything that works in preview works in production, which is a property you only get if the build is not different in the two paths.
The project also documents its sponsorship, and one of the sponsors is directly relevant to how the site is delivered. CDN acceleration and security protection for the project are sponsored by Tencent EdgeOne, and the Crowdin badge in the acknowledgements is for the localisation platform, with the Crowdin project linked directly. The site therefore runs on Cloudflare Workers for the app layer with an edge CDN in front for delivery, which is a reasonable pairing for a site that serves a lot of static assets and download links to a global audience.
Funding is also handled through Buy Me a Coffee and GitHub Sponsors, and the acknowledgements section thanks the people who have supported the project.
Localisation with Crowdin and vue-i18n
Localisation is handled with Crowdin, and the repository has a crowdin.yml at the root, which is the configuration file Crowdin reads to know where the source strings are and where the translations go. The project documentation says contributions to help translate are welcome.
On the code side, the internationalisation is Vue's own. vue-i18n at 11.4.4 is the runtime, and @intlify/unplugin-vue-i18n at 6.0.8 is the build-time integration that compiles the message bundles and resolves the locale at build time, which is what makes the site a static set of pages rather than a server that renders per request.
The coupling with the site framework is what makes the arrangement worth copying. VuePress 2 is a static site generator, so a page has a fixed path and a fixed set of strings. If the strings are in the bundle at build time, then every language is a separate build output, and the deployment to Workers is just a set of static assets with a rewrite rule. The alternative, a runtime translation lookup, would need a server that knows the locale and would complicate the deployment.
The consequence for a contributor is that a translation change goes through Crowdin and a rebuild, not through a pull request that changes the site directly. That is the standard trade for a community translation programme, and it keeps the repository from accumulating a directory of per-language files that nobody maintains.
Against a plain static site, and against the game repository
The comparison with a plain static site generator is the first one. A documentation site needs routing, a search index, a theme, and a way to express content that is partly data and partly prose, which is where VuePress and the Hope theme earn their place. The cost is the release candidate pins, which are the price of building on a tool that has not had a stable release for this generation.
The comparison with the game repository is the one to keep straight. The site holds the guides and the download links, the feedback module, and the level editor and almanac data tooling, while the game code lives in a separate repository. That separation is why the site can be deployed independently and why the site's release version numbers, which the recent releases show as 0.15.0 and lower, do not correspond to the game version.
There is also the deployment split worth understanding. The site is the VuePress project, and the game is the separate Cocos-based project that has a Docker image published under gaozih/pvzge for local deployment. Two artifacts, two repositories, one project, and a shared Discord community.
The practical caveat for anyone building on this setup is the online play build, which the documentation warns may not be the latest version and may load slowly. That is a fair warning for a browser build of a full game, and it is the kind of thing that matters when you are trying to reproduce a bug reported against a specific version.
Editorial conclusion
Adopt this repository if you are working on the PvZ2 Gardendless project and want to change the site, the guides, or the data checks alongside the game. Do not treat it as the game source, since the game lives in a separate repository and this one is only the site. Verify first that your VuePress 2 release candidate versions still build with your Node version, because the whole documentation stack is pinned to release candidates.
Frequently asked questions
What does the pvzg_site repository contain?
It is the open source repo of the website of PvZ2 Gardendless, a rewritten Plants vs Zombies 2 built with web technologies including the Cocos engine. The site hosts download links, game guides, and a feedback module, while the game source lives in a separate game repository.
How is the site built and deployed?
The site is a VuePress 2 project. The build runs vuepress-vite build src, the deploy script runs that build followed by wrangler deploy, and the preview script runs the same build followed by wrangler dev, so a preview uses the production bundle against a local Workers runtime.
What are the check and build scripts in the site repository for?
They validate and generate the game's data rather than the website. There is a check for the almanac pages, a build and a check for the level editor board objects, a round trip check for level editor waves, and unit plus stress tests for the plant decoding solver.
How is PvZ2 Gardendless localised?
With Crowdin, configured through a crowdin.yml at the repository root, and vue-i18n with the intlify unplugin on the code side. The build-time plugin means each language is a separate static build output, and translation changes arrive through Crowdin rather than through pull requests.
Can I play the game online or run it locally?
There is an online build at play.pvzge.com, and the documentation warns that the online version may not be the latest version and may load slowly. For local deployment the project publishes a Docker image at gaozih/pvzge, and the site is at pvzge.com.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/gzh0821-pvzg-site)Was this useful?