Authoring

Ship your own catalog. The same tooling that drives the official @main registry works for any team or studio that wants its own.

A registry is just a directory of item.json manifests with companion source files. gamecn-registry build walks that directory and emits a deployable static site — no server, no database.

The 3-step path

1. Author items

Each item is a folder under <your-registry>/<engine>/<name>/:

my-registry/
  phaser/
    custom-camera/
      item.json                # the manifest
      systems/
        CustomCamera.ts        # source files referenced by the manifest
      docs/
        custom-camera.md       # markdown shown on the catalog page

The shape of item.json is documented in item.json.

2. Build

npx gamecn-registry build \
  --src my-registry \
  --out dist \
  --base-url https://my-registry.example.com

The builder validates each item against the schema, inlines small text files, hashes binary files into dist/assets/<sha256> with SRI integrity, and writes per-item manifests to dist/r/<name>.json plus the index at dist/registry.json.

3. Deploy

dist/ is a regular static site. Drop it on Cloudflare Pages, Vercel, S3, or any HTTP server. See Host your own for deploy specifics.

What you get

  • Versioning. Each item declares its own semver version. Bump per item; consumers' lockfiles pin to specific versions.
  • Asset deduplication. Two items referencing the same binary asset share a single content-addressed file in dist/assets/.
  • Compatibility checking. Authors declare engine version ranges; the CLI validates against the consumer's project on install.
  • Private mode. Add auth headers to your namespace config and the CLI handles bearer tokens / ${ENV_VAR} interpolation cleanly.

Distribution

Two paths to get items into a user's project:

  1. Ship a hosted registry. Users add your namespace to their gamecn.json#registries and gamecn add @your-org/foo works.
  2. Direct GitHub install. Users run gamecn add gh:your-org/your-registry/dist/r/foo.json#v1.0.0 — no namespace config needed, just a Git tag.

The first is friendlier for end users. The second is the path of least resistance for early-stage registries.