Chinese Free Web Font Storage: font files as repository content

The repository is a package folder, not a library you install

KonghaYao/chinese-free-web-font-storage, with 1469 stars, 57 forks, 15 open issues, JavaScript as its primary language and a default branch named `branch`, is not a library you install and call. It stores font files as repository content. A contributor drops font source files into a folder under `packages/`, and the project's own tooling packages and groups them. The Netlify site at `https://chinese-font.netlify.app/` is the browsing front end, and the README splits its audience in two: developers copy a CSS link from the site, designers follow a GitHub icon down to the raw font file. Three companion projects carry the actual work. cn-font-split performs the character slicing, vite-plugin-font wires the result into Vite, Next, Nuxt or Webpack, and font-now takes a direct upload and returns a CDN link. The stated reason for slicing is character volume: a full CJK face is too heavy to hand to every page, so a split lets a site cover whole text without shipping the whole face.

Three version numbers and no release page

The README opens with 中文网字计划 v6, so the sixth generation reads as the headline version. The index package at the repository root says something else: name `@chinese-fonts/index`, version 1.2.1, with a description field that calls itself the project index file. The engine that does the slicing is pinned separately as `cn-font-split` at `^7.2.9` in devDependencies, and it lives in its own repository. Then there is the publishing story. The README says the work is 已发布到 NPM, yet the repository has no GitHub releases, so there is no release note, no tag history and no changelog to consult. The default branch is called `branch` rather than `main` or `master`, which matters at clone time. The last recorded push is 2026-06-16. Following this project means reconciling three counters and two distribution channels by hand.

MIT in the README, ISC in the manifest

License metadata says MIT, and the README prints MIT License under its 仓库证书 heading, but the manifest at the root declares `"license": "ISC"`. Two different SPDX identifiers describe the same codebase and nothing in the repository settles the conflict. This article does not settle it either. What is clear is that the repository license covers the project's own code and configuration, not the fonts, which stay with their makers. The project is deliberate about that boundary: font head metadata is exported into each font's detail page so the maker and the licensing terms can be read before use, and the intake rule is one line, 我们只接收免费商用的字体. Nothing lands in `packages/` by itself. The pull request step states that submitted fonts get a human review and a human upload, so the licence question is answered per font, not once for the repository.

One contribution path, two package managers

A pull request is the only route that adds a font, and the steps are terse. Prepare a font link and its license information, fork the repository, install, run a plop template command using the font's pinyin abbreviation as the argument, drop the font files into the folder the template created, then build that one font. Node 18 or newer is required.

npm i # 安装项目

npm run new dyh # dyh 是字体的中文拼音的第一个英文组合
# 完成后将会在 packages 文件夹自动模板创建一个 dyh 文件夹

# 然后你在 packages/dyh/fonts 文件夹中放入您的字体文件

pnpm build --single=dyh  # 尝试打包文件

Two package managers appear across those commands. The install step is npm, the build step is pnpm, and the root holds both `package-lock.json` and `pnpm-workspace.yaml`, the workspace file being what makes a pnpm invocation meaningful at all. Nothing states which of the two lockfiles is authoritative, so a contributor following these instructions installs with one manager and builds with another.

Six npm scripts and a dev command with no declared dependency

The manifest defines six scripts. `new` runs plop, the template step above. `build` runs `node ./scripts/build.mjs`. `build:cdn` runs that build with `--mode=rebuild`, then a move script, then the index script. `index` runs the index script on its own, and `test` runs the build with `--mode=check`. The sixth is the odd one out: `dev` is `ws --port=2048`, and nothing in devDependencies provides that command. The declared set is cn-font-split, dotenv, fs-extra, glob, imagekit, md5, mri, p-limit, plop and semver. Two further details sit awkwardly beside it. A `test-size.sh` at the root is invoked by no script in the manifest, and the published package declares `files` as an empty array with `main` pointing at `index.json`, which makes the index file the package's only entry point. The `author` and `keywords` fields are both empty.

Imagekit for delivery, FontSource for the lookup page

Delivery runs on someone else's infrastructure. Imagekit.io provides the static file solution for the fonts, and they are deployed there, which fits `imagekit` at `^5.2.0` in devDependencies. The project also says it still hopes for a public CDN that keeps serving fonts for free the way Google Fonts does, so the hosting question is not treated as settled. Google Fonts is folded into the site's own font lookup page, built on FontSource's npm repository for both the data and the files, because some regions have no easy route to Google's font pages. Two usage warnings travel with the output. Some Chinese fonts contain no Latin glyphs, so English text has to come from Google Fonts alongside them. And when fonts are pulled in through `result.css`, assigning two font families to one DOM element can produce errors, a failure that shows up as mangled text in the browser rather than a message at build time.

An empty collaboration heading and a badge with no label

Three parts of the README are scaffolding with nothing behind them. The 开发与合作 heading carries no text. The contributors block is an anchor to the repository's contributors graph with no content inside it, and the Netlify deploy link at the top has no label, so it renders as nothing at all. The upload and deployment procedure is deliberately kept elsewhere: the README says it was written into Developer.md so the author would not forget how those steps work. What stays in the README about collaboration is the intake rule. A contributor can open an issue with a font link and its license information, or send a pull request, and in both cases a person checks the font and performs the upload. With 15 open issues on the repository, that human step is the real bottleneck in getting a font into the library, not the build.

Editorial conclusion

Treat this repository as font content plus a small build pipeline, not as a package you install. Before depending on it, check three things yourself: which number you treat as the project version, since the README, the index package and the split dependency each carry a different one; which license governs the code, since MIT and ISC both appear on it; and whether each font you plan to ship carries the licensing terms its maker set. The two DOM level warnings in the README deserve a second read, because both fail quietly in the browser rather than at build time.

Frequently asked questions

Official sources

1. Issues
2. KonghaYao/chinese-free-web-font-storage on GitHub
3. License: MIT
4. Project website
5. README