ZalithWebsite is the launcher's site, and the front end never touches the download API

A bilingual README for a website, not for a launcher

The scope is stated in the first line and repeated in English underneath it: this is the source code of the Zalith Launcher's official website, and the project description calls it the official website of ZalithLauncher. Nothing about the launcher program, its versions or its binaries is in this repository, which is why a search for the launcher itself lands elsewhere. The site is published at zalithlauncher.cn, the repository is MIT licensed, the primary language is TypeScript, and the default branch is main. There are no GitHub releases, so deployments are tracked through commits rather than versions, with the last commit pushed on 19 September 2026. The README is written in Chinese and English side by side, which fits a site that itself ships multiple languages through react-i18next.

Five pnpm commands, and a build that runs three scripts first

Local development is five commands:

pnpm install
pnpm dev        # 启动开发服务器
pnpm build      # 构建产物（含构建信息与博客数据生成）
pnpm lint       # ESLint 检查
pnpm preview    # 预览构建产物

The package manager is pinned in the manifest itself, with packageManager set to [email protected] and a pnpm-lock.yaml and pnpm-workspace.yaml in the repository, so a clone with npm or yarn is not the supported path. The build script is longer than it looks, because it is a chain rather than one command: it runs build:info, then build:blog, then build:sitemap, then a TypeScript project build with tsc -b, and only then vite build. The first three are small TypeScript scripts executed through npx tsx, named scripts/build-info.ts, scripts/build-blog.ts and scripts/build-sitemap.ts. So a failing blog post or a missing metadata file stops the build before any bundling happens, which is a deliberate ordering for a site that generates content rather than only serving it.

Four download sources, each with a recorded authorisation

The download page aggregates several channels, and the README states the rule plainly: every mirror is included only after the project side has confirmed authorisation, with two issues numbered 59 and 60 cited as the record. The table names four. GitHub official is run by the ZalithLauncher project itself, supports both ZL1 and ZL2, and is marked as the official channel. The FrostLynx mirror, with its main site at fyhub.cn, supports ZL2 only and is marked authorised under issue 60. The Lemwood resource station supports ZL1 and ZL2 and is noted as authorised with the site maintainer providing it. The 239LAN mirror, with its main site at mirror.cxsjmc.cn, supports ZL2 only and is authorised under issue 59. The asymmetry is the practical point: a visitor who needs ZL1 has two options rather than four, and a contributor adding a fifth source is expected to record who authorised it rather than just pasting a URL.

The front end never calls the download API

One line explains the architecture of the download page better than any component diagram would: web download links uniformly redirect to the mirror's main site verification page, the main site performs verification and node scheduling, and the front end does not directly call the program download API. So the website's job ends at the click. Whoever owns a mirror handles the verification step and decides which node serves the file, and the site itself never learns which one you got. That design keeps provider keys, rate limits and anti abuse logic out of a static site, which is the sane way to distribute files from several hosts. It also means a download that fails is almost never a bug in this repository, and that the reliability of the whole page depends on four external main sites staying up.

useLatestRelease.ts is where versions and mirrors meet

The folder layout is documented in six bullets and one of them carries the whole data flow. src/pages holds the page components, src/components holds shared components including the download page Download.tsx, src/hooks/useLatestRelease.ts fetches version information together with the per-mirror download source data, and src/i18n holds the multi-language copy. That hook is the point where the version table and the mirror table meet, which is why the download page can show both without hardcoding either. Content lives outside src entirely: content/blog holds the blog Markdown sources, which are built by scripts/build-blog.ts, and scripts holds the build helpers in general. The build dependencies match that layout, with glob to find files, gray-matter to read front matter and marked to render Markdown, plus a yaml dependency for data files that are not JSON.

Tailwind 4 through the Vite plugin, with a workspace file on top

The styling stack is Tailwind CSS 4 wired in through the Vite plugin rather than through a separate PostCSS pipeline, though autoprefixer and postcss are both present in the development dependencies along with the typography plugin. Class handling uses the usual pair of clsx and tailwind-merge, icons come from lucide-react, and animation is framer-motion, which matches the README naming React Router for routing, react-i18next for multi-language text and framer-motion for animation. React itself is on version 19 with React Router 7, TypeScript is around 6.0, and Vite is on 8. Linting is ESLint 10 with an eslint.config.js at the root, and the TypeScript configuration is split the usual Vite way into tsconfig.json with app and node variants. A pnpm-workspace.yaml sits at the root even though the visible structure is a single app, which suggests the workspace exists for scripts or future packages.

Editorial conclusion

This repository suits a contributor who wants to fix a page or a translation on the launcher's official site, since the folder layout is small, the command set is five pnpm scripts, and the blog pipeline is Markdown compiled at build time. It does not suit anyone looking for the launcher itself, or for the download files, because nothing about the program or its binaries is in here and every web link leaves the site immediately. Before you contribute, check the download source table rather than assuming a mirror is interchangeable, because support differs between ZL1 and ZL2, and remember that the authorisation notes reference specific issue numbers. If you add a mirror, follow the existing pattern of recording who authorised it, and expect the build to run three scripts and a TypeScript check before Vite ever starts.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository