Repository navigation
fix(odf): fail validation when package parts are unreadable - #590
productdevbook merged 2 commits into
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
`validateOdfParts` had a single caller: the test drives the CLI through `spawnSync` and never imports the module, so the extraction bought indirection — eight injected parameters, including `log` — and nothing else. The counting change is back in the loop it belongs to. The test was a `.mjs` file, which no tsconfig project looks at, so it sat outside `bun run test`'s typecheck. It is `.test.ts` now, listed where CONTRIBUTING says a test needing node builtins goes. And `extract` resolves the ZIP reader relative to `--dist` instead of whatever sits in ../dist, which is what makes the stub bundle force the `unzip` fallback: the missing-part run can now assert that the three parts which *did* come out are still reported valid. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Taking this with one commit on top. The behaviour is right and matches #566: a part that will not come out of the package is a failed check, and a manifest check nobody ran says so. Two things changed:
While there: |
Summary
Closes #566. The current catch-and-continue path can print “All parts valid.” and exit 0 after checking no required part.
Evidence
main: a missingsettings.xmland an unreadable package both exit 0, and the skipped manifest check is not identified.bun run testreports 239 passing test files and 10,695 passing tests, plus one existing failure intest/huge-part-error.test.tsfor The #503 fix never fires on Node: TextDecoder throws Error/ERR_STRING_TOO_LONG, not RangeError #516. The same The #503 fix never fires on Node: TextDecoder throws Error/ERR_STRING_TOO_LONG, not RangeError #516 failure reproduces on clean upstreammain(238 passing test files; 10,692/10,693 tests pass).unzipandjavastubs to exercise the failure paths.Merge Danger
Door: two-way
Blast Radius: Low
A failed extraction now makes the validation command exit non-zero instead of reporting a false pass.
Summary by CodeRabbit