fix(parser): strip leading UTF-8 BOM before JSON.parse#40
Open
dmchaledev wants to merge 1 commit into
Open
Conversation
SBOM files exported by some generators and Windows text tooling carry a leading UTF-8 byte order mark (U+FEFF). Such files are valid on disk, but parse() passed them straight to JSON.parse, which throws a cryptic "Unexpected token" error — making otherwise-valid SBOMs undiffable and the CLI crash on the tool's core operation. Strip a single leading BOM in the string-input path before parsing. Only a BOM at the very start is removed; BOMs inside string values are preserved. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WeWeVvWTVLxzex3YDXuF7p
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
SBOM files exported by some generators and by Windows text tooling carry a leading UTF-8 byte order mark (
U+FEFF, bytesEF BB BF). Such files are perfectly valid on disk, butparse()(src/parser.ts) passes the raw string straight toJSON.parse, which throws a cryptic error:For a tool whose core operation is diffing SBOM files, this means an entire class of real-world inputs is undiffable and the CLI hard-crashes on the happy path. The error message doesn't even hint that a BOM is the cause.
This is orthogonal to the other in-flight PRs/issues — none touch pre-
JSON.parseinput handling. It is distinct from #21 (which is about wrong-format JSON): a BOM-prefixed SBOM is a valid SBOM that the tool rejects.Reproduction (before this change)
Change
In the string-input path of
parse(), strip a single leading BOM before parsing:Tests
Added to
src/__tests__/parser.test.ts:format/componentsintact).Verification
npm test→ 31 passing (2 new)npm run lint→ cleannpm run typecheck→ cleannode dist/cli.js old.json new.jsonagainst two real BOM-prefixed (EF BB BF) CycloneDX files — previously crashed, now produces a normal diff report.🤖 Generated with Claude Code
https://claude.ai/code/session_01WeWeVvWTVLxzex3YDXuF7p
Generated by Claude Code