Files

Tianyi Cui 605587e79c docs(rfc): classify RFCs by kind via path-encoded subdirectories

Add a second axis to every RFC — its class (feature, bug-fix,
simplification, architecture, process, testing) — encoded in the path
as docs/rfc/{lifecycle}/{class}/file.md. The folder is the label, so
the closed set is enforced by structure rather than a parsed field.

Two new doc-sync gates back it:
- verify-rfc-classification: every RFC sits in a valid class folder and
  the README index lists it under the matching lifecycle→class heading.
- verify-doc-refs: every docs/*.md path cited in a packages|examples TS
  comment resolves — closes a drift class verify-md-links can't see, and
  catches the four comment refs this reorg moved.

The README gains a Classification section explaining the taxonomy and
per-class index sub-sections. A self-referential process RFC records why
the scheme is path-encoded and gated.

2026-06-20 22:29:45 +08:00

2.7 KiB

Raw Blame History

RFC: tsdown for JS bundling instead of dumble

Status: implemented (accepted 2026-06-11)

Context

The initial build used dumble, the cordiverse zero-config esbuild wrapper that upstream Cordis itself builds with — maximum alignment with the vendored packages' conventions (it reads each package.json and infers entries/formats from the exports field). But dumble is a liability as a load-bearing tool in this repo: v0.2.x, ~530 npm downloads/week, effectively one maintainer, and we were invoking it through a custom orchestration script (scripts/build.ts) because it has no workspace mode.

Build output currently matters only for pnpm run build + publint (nothing publishes yet; dev/test/demo run unbuilt via tsx), so the switching cost is at its lowest now and only grows once packages publish.

Decision

Replace dumble with tsdown (rolldown-based, ~2.5M downloads/week, VoidZero-backed, actively released):

Root tsdown.config.ts with workspace: ['vendor/*', 'packages/*'] (explicit globs, not workspace: true, which would also pick up examples/* — they have package.json files but are not pnpm workspaces).
Shared shape: entry src/index.ts, outDir: 'lib', ESM, platform: node, target: es2024, fixedExtension: false (keeps .js for "type": "module" packages), dts: false (tsc -b owns declarations), clean: false (lib/ holds tsc's .d.ts output).
Two per-package overrides in vendor/ (ours, like the regenerated tsconfigs; logged in vendor/README.md): schemastery (dual .mjs/.cjs via outExtensions), logger-console (two single-entry passes so the shared base class is inlined into each entry instead of a hash-named chunk, matching upstream's published shape).
scripts/build.ts deleted; pnpm run build = tsc -b && tsdown.

Alternatives considered: direct esbuild script (most established engine, zero wrapper risk, but hand-maintains the per-package spec table tsdown's workspace mode gives us); pkgroll (closest drop-in philosophically, but 78k dl/wk and Rollup-based — strictly weaker maintenance story than tsdown); keep dumble (perfect upstream alignment, unacceptable bus factor).

Consequences

Output file lists are byte-for-byte-list identical to dumble's (verified by snapshot diff at migration time); externals still come from each package's dependencies/peerDependencies. We give up dumble's exports-field inference — new packages with non-default shapes need a per-package tsdown.config.ts instead of just package.json fields. Future option: tsdown could also absorb declaration bundling (isolatedDeclarations) if tsc -b ever becomes the bottleneck; that would be a new RFC.

2.7 KiB Raw Blame History

RFC: tsdown for JS bundling instead of dumble

Context

Decision

Consequences

2.7 KiB

Raw Blame History