Context: the publish-time protocol tear guard (follow-up to the #219/#221 tear — published protocol@0.2.0 was missing the A20 exports while runtime@0.4.0-pre.* imported them) compares exact publish-artifact identity: in-tree protocol/src/** + deno.json byte-hashes vs the registry's <version>_meta.json file checksums. Red means "publishing would produce a torn set", with zero judgment.
The exactness is deliberate — protocol's compatibility surface is substantially value-level and behavioral (Symbol.for brand-key strings, envelope wire shapes, registry side effects), so interface-level canonicalization has false negatives concentrated in the dangerous class. #216 is the proof: the caret-breaking event was a brand-key string rename; had the export names not renamed alongside it, a type-surface diff would have shown nothing.
But exact identity is conservative: comment edits, reformatting, and non-exported internal refactors force a patch bump. Ideas parked here in case the false-positive rate turns out to matter:
- Comment/whitespace-stripped content hashing — swc/esbuild parse → strip comments → hash. Still content-level (deliberately not interface-level); removes the noisiest false-positive class while keeping value-level changes visible. Build only if comment-churn bumps actually annoy in practice; in a five-file, mostly-frozen package the rate may be zero. (Note there is currently no
deno fmt gate, so formatting drift is also in the false-positive class.)
deno doc --json advisory surface diff as a breaking-label reminder — PR-time, findings-only, never required: diff the exported surface against the last cut tag; if it changed and no breaking/* label is present, prompt for classification. Opposite polarity from the tear guard: it may under-catch because it only prompts judgment, never certifies compatibility. Already in the toolchain; needs source-position stripping before diff.- Surveyed and rejected as the guard itself: api-extractor (ecosystem-standard canonical API reports, but tsc/npm-world tooling in a Deno-first repo, and type-surface only); JSR API fingerprints (don't exist — per-file hashes are all it exposes).
Do not weaken the publish-time guard below content level: its red must be unarguable.
Context: the publish-time protocol tear guard (follow-up to the #219/#221 tear — published
protocol@0.2.0was missing the A20 exports whileruntime@0.4.0-pre.*imported them) compares exact publish-artifact identity: in-treeprotocol/src/**+deno.jsonbyte-hashes vs the registry's<version>_meta.jsonfile checksums. Red means "publishing would produce a torn set", with zero judgment.The exactness is deliberate — protocol's compatibility surface is substantially value-level and behavioral (
Symbol.forbrand-key strings, envelope wire shapes, registry side effects), so interface-level canonicalization has false negatives concentrated in the dangerous class. #216 is the proof: the caret-breaking event was a brand-key string rename; had the export names not renamed alongside it, a type-surface diff would have shown nothing.But exact identity is conservative: comment edits, reformatting, and non-exported internal refactors force a patch bump. Ideas parked here in case the false-positive rate turns out to matter:
deno fmtgate, so formatting drift is also in the false-positive class.)deno doc --jsonadvisory surface diff as a breaking-label reminder — PR-time, findings-only, never required: diff the exported surface against the last cut tag; if it changed and nobreaking/*label is present, prompt for classification. Opposite polarity from the tear guard: it may under-catch because it only prompts judgment, never certifies compatibility. Already in the toolchain; needs source-position stripping before diff.Do not weaken the publish-time guard below content level: its red must be unarguable.