caz resolves one argument four different ways, and its --offline flag still reaches GitHub

The offline flag still reaches GitHub on a cold cache

The options table gives you two switches and no more: -f, --force to overwrite when the target exists, and -o, --offline to try to use an offline template. The recipe that follows spells out what the second one actually does.

$ caz nm my-project --offline
$ caz minima my-project --name my-proj
$ caz nm my-project --debug
$ caz list [owner] [-j|--json] [-s|--short]

Run that first command and CAZ looks for a cached copy of the nm template, and if nothing is cached it downloads the template from GitHub. So the flag selects a preference, not a network state. A machine with an empty cache and no route to github.com still fails, and the failure arrives after a lookup rather than up front. Nothing in the options table warns about this, and the usage line at the top of the quick start carries the flag as if it were a mode.

Runtime libraries are declared under devDependencies

The features list claims zero dependencies, and the manifest makes that literal in a way that is worth reading carefully. package.json declares no dependencies key at all. What the CLI needs at run time sits in devDependencies: adm-zip 0.5.10, cac 6.7.14, ini 4.1.1, fast-glob 3.3.1, lodash 4.17.21, env-paths 3.0.0 and node-fetch. The presence of @types/adm-zip, @types/ini, @types/semver and @types/validate-npm-package-name says the same libraries are imported by the shipped code.

So the claim describes what npm installs for you, not what the shipped JavaScript contains. The files array publishes dist and nothing else, and that dist comes out of tsup, configured with two entry points, src/index.ts and src/cli.ts, with splitting on and minify off. main is dist/index.js, types is dist/index.d.ts and bin is dist/cli.js, which is what npm install -g caz ends up executing.

Ten feature bullets and a promise of reasons

The feature list is ten one line bullets. Nine of them concern size or shape: easy to use, light-weight, zero dependencies, template-based, configurable, extensible, TypeScript, high efficiency and use modern API. The tenth is the odd one out, insisting that the tool stays capable despite being small. Directly underneath sits a note promising specific reasons to follow. The rest of the file never delivers them.

What comes next is a prerequisites list, an install command, a usage line, seven recipes, a template catalogue, configuration, template authoring and a set of administrative sections. None of them returns to the bullets. Zero dependencies is the only claim on the list a reader can check from the repository, and section two of this article checks it out. High efficiency and use modern API carry no measurement, no version and no comparison anywhere in the visible text. The introduction also frames the tool as scaffolding for the author's personal productivity, inspired by Yeoman and Vue CLI 2, which is a narrower claim than a globally installed command invites.

One argument resolves four different ways

The template argument is polymorphic, and the recipes show each shape.

$ caz nm my-project
$ caz nm#typescript my-project
$ caz zce/nm my-project
$ caz ~/local/template my-project
$ caz https://cdn.zce.me/boilerplate.zip my-project

A bare name resolves against the caz-templates organisation, which is also the default owner for caz list. An owner/repo pair pulls from your own public repository, and the text states plainly that a public repository is necessary. A hash suffix selects a branch, so nm#typescript reads the typescript branch of caz-templates/nm. A path with a slash that is not a repository pulls from your file system, and a URL ending in .zip is downloaded and extracted.

The list subcommand takes the owner as its only argument and offers -j for json output and -s for short output. Running caz list with no arguments is the documented way to see the official catalogue in real time rather than trusting the file.

Answer flags come from templates, not from the options table

The documented options are -f, --force and -o, --offline. Two other flags appear in the recipes with no entry in that table.

The first is prompt override. Running caz minima my-project --name my-proj skips the next name prompt, which means every answer a template asks for becomes a command line flag of the same name. caz does not need a table for them because the template owns the question set, and the flag is only meaningful against the template that asks for it.

The second is debug mode. The --debug flag opens a mode where an exception, once it happens, prints its details automatically, which the text calls out as useful for finding errors in a template rather than in the CLI. A command like caz nm my-project --debug therefore changes what you see when a template throws. Neither flag is documented as part of the interface, so a reader building scripts against caz has to read the template to learn which flags exist.

Three of the ten official templates carry a construction marker

The catalogue lists ten templates under the caz-templates organisation: template, nm, vercel, react, vue, vite, electron, mp, jekyll and x-pages. The first six are presented as ready. The last four are not: electron, mp and jekyll each carry a construction marker in the list, and the marker sits in the entry itself rather than in a footnote.

The named targets differ in kind. nm is for node modules, vercel for apps on Vercel, react and vue for modern apps, vite for vue.js apps, mp for WeChat mini programs, jekyll for a Jekyll site, x-pages for static sites, and template for authoring new caz templates. So a third of the catalogue is scaffolding for targets that are still being built.

One line in this section tells Chinese users that all templates are hosted on GitHub and that a mirror exists on coding.net, and it links to an anchor labelled for that mirror. That anchor is not one of the entries in the table of contents.

Configuration is a home directory ini file with undocumented defaults

CAZ reads its configuration from ~/.cazrc, and the file shows a default block written in ini syntax. The one comment visible in that block reads `; template download regist`, which names the subject of the block, and no key name follows it there. So the location of the configuration is documented and its contents are not: a reader learns that template download registration is configurable and nothing about which keys exist or what they accept.

The repository layout gives the same impression from the other side. At the root sit src/, test/, docs/, types.d.ts, tsconfig.json, .editorconfig, CHANGELOG.md, LICENSE and two readme files, README.md and README.zh-CN.md, which means the project keeps its documentation in English and Simplified Chinese side by side. A hand written types.d.ts sits at the root even though tsup also generates declarations from src/index.ts with resolve turned on.

Commits continue three years past the newest tag

Three releases are recorded: v1.0.0 on 2022-03-25, v1.1.0 on 2022-04-19 and v2.0.0 on 2023-07-26. The version in package.json is 2.0.0, so the manifest agrees with the newest tag. The most recent push is dated 2026-09-19, which leaves more than three years of commits with no release to point at.

The development toolchain around those commits is pinned to exact numbers rather than ranges: @commitlint/cli 17.7.1, @commitlint/config-conventional 17.7.0, husky 8.0.3, lint-staged 15.2.4 and @types/node 20.11.22. The hooks are wired in the manifest itself, with prepare running husky install .github/husky, lint-staged running ts-standard --fix over ts and js files, and renovate extending a shared config named zce. Linting goes through ts-standard and tests through vitest run. The type definitions target Node 20 while the prerequisites accept Node 16 or newer, so the floor and the type baseline sit two majors apart.

Editorial conclusion

Suit caz if you already know which template you want and you want a global or npx install that reads a plain ini file from your home directory. Check three things first: whether the template lives in a public GitHub repository, because caz states that as a requirement, whether your cache is warm enough for --offline to stay off the network, and whether the template answer flags you pass are documented anywhere outside its own prompts. Anyone depending on release cadence should note that the newest tag is v2.0.0 from 2023-07-26 while commits have landed as recently as 2026-09-19.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. zce/caz on GitHub