feat(enrichment): treat Zstandard (.zst) archives as binary assets - #3128
Conversation
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
|
Warning 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ⏸️ Gittensory review result - manual review recommendedReview updated: 2026-07-04 18:16:51 UTC
⏸️ Suggested Action - Manual Review Review summary Nits — 3 non-blocking
Review context
Contributor next steps
Signal definitions
🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.
|
The asset-weight analyzer flags heavy binary blobs whose sizes are not in the textual diff, but its archive/compression extension set covered gz/tgz/bz2/xz/7z/rar and missed Zstandard (.zst) — now a common committed artifact (npm/cargo caches, compressed model shards). Add it so a PR that commits a large .zst blob is weighed like other binary archives. Only the final extension is matched, so a compound name like `.tar.zst` resolves to `zst`, and the lookup stays case-insensitive. src/review/rag.ts already classifies .zst as binary; this brings the size analyzer in line.
c88ae77 to
67b78a9
Compare
Summary
The
asset-weightanalyzer flags heavy binary blobs whose byte sizes never appear in the textual diff (they show as "Binary files differ"). Its extension set already covers the common archive/compression formatsgz/tgz/bz2/xz/7z/rar, but missed Zstandard (.zst) — now a routinely-committed artifact (npm/cargo caches, CI caches, compressed model shards). A PR that added or grew a large.zstblob therefore slipped past the size-bloat signal.This adds
"zst"toBINARY_EXTS:foo.tar.zstcorrectly resolves tozst.toLowerCase()path), so.ZSTis covered.svg/json/…) remain excluded — their bytes are already in the diff.Consistency anchor:
src/review/rag.ts'sBINARY_EXT_REalready classifies.zstas binary, so the repo already treats.zstas a binary asset — this brings the size analyzer in line with that existing decision.No linked issue
This is a no-issue PR by design: a self-contained detection-coverage improvement that adds one archive extension (
.zst) to theasset-weightanalyzer'sBINARY_EXTSset plus its unit test, touching onlyreview-enrichment/. There is no behavior change beyond recognizing the new extension, so no tracking issue is needed. It mirrors the accepted no-issue precedent for the very same file —webp/avif/heic/heif(e.g. #3089).Scope
type(scope): short summaryConventional Commit format.CONTRIBUTING.mdand does not reintroduce GitHub Pages, VitePress,site/, orCNAME.asset-weight.tsand its unit test, mirroring the accepted precedent forwebp/avif/heic/heif. The summary explains why an issue is not needed.Validation
git diff --checknpm run actionlintnpm run typechecknpm run test:coverage— nosrc/**lines changed (this change is underreview-enrichment/, which Codecov does not measure), socodecov/patchhas no diff to gate; suite is green.npm run test:workersnpm run build:mcpnpm run test:mcp-packnpm run ui:openapi:checknpm run ui:lintnpm run ui:typechecknpm run ui:buildnpm audit --audit-level=moderate.zstpositive, compound.tar.zst, and uppercase.ZSTcases are added to theisBinaryAssetunit test;npm run rees:testpasses (all review-enrichment tests green, analyzer-metadata check clean).All of the above run as part of
npm run test:ci(green).Safety
Notes
Analogues followed end-to-end: the merged
feat(enrichment): treat HEIC/HEIF images as binary assets(#3089) and the original asset-weight analyzer (#1621) — same file, same additive shape, same test pattern.