Skip to content

fix(opencode): strip all leading BOMs in Bom.split (#33092)#33222

Open
fancive wants to merge 1 commit into
anomalyco:devfrom
fancive:fix/bom-split-multiple-boms
Open

fix(opencode): strip all leading BOMs in Bom.split (#33092)#33222
fancive wants to merge 1 commit into
anomalyco:devfrom
fancive:fix/bom-split-multiple-boms

Conversation

@fancive

@fancive fancive commented Jun 21, 2026

Copy link
Copy Markdown
Contributor

Issue for this PR

Closes #33092

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

Bom.split() stripped only the first U+FEFF via text.slice(1), so content with several consecutive leading BOMs kept the extras. Because join() calls split() before re-adding a single BOM, each write/edit cycle removed at most one extra BOM — so content with N leading BOMs needed multiple edit passes to normalize down to one.

The fix mirrors splitBom() already in packages/core/src/file-mutation.ts: replace slice(1) with text.replace(/^\uFEFF+/, "") so all leading BOMs are stripped in a single pass, and derive the bom flag from whether anything was stripped. join() is unchanged — it already calls split() first, so multi-BOM content now normalizes to exactly one (or zero) BOM in one pass, and the write / edit / apply_patch callers are fixed transitively.

How did you verify your code works?

Added packages/opencode/test/util/bom.test.ts (this util had no tests) covering no-BOM, single, multiple consecutive, and non-leading BOMs, plus join() normalization — bun test test/util/bom.test.ts → 9 pass / 0 fail. bun turbo typecheck --filter=opencode and oxlint are both clean.

Screenshots / recordings

N/A — not a UI change.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

Bom.split() removed only the first U+FEFF via text.slice(1), so content
with multiple consecutive leading BOMs kept the extras. Because join()
re-runs split() before re-adding a single BOM, each write/edit cycle
dropped at most one extra BOM, so a file with N leading BOMs needed
several edit passes to normalize to one.

Align split() with the existing splitBom() in
packages/core/src/file-mutation.ts and strip all leading BOMs via
/^+/. join() is unchanged; multi-BOM content now normalizes to
exactly one (or zero) BOM in a single pass, fixing the write/edit/
apply_patch callers transitively.

Add unit tests for split()/join() (the util had none) covering no-BOM,
single, multiple consecutive, and non-leading BOMs.

Fixes anomalyco#33092

Claude-Session: https://claude.ai/code/session_01444Qm3LDDrcHSy1HtETM6G
@github-actions github-actions Bot added contributor needs:compliance This means the issue will auto-close after 2 hours. and removed needs:compliance This means the issue will auto-close after 2 hours. labels Jun 21, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Thanks for updating your PR! It now meets our contributing guidelines. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[bug] Bom.split() fails to normalize multiple BOMs

1 participant