GeezerVison

Fixes #65458

Wtf8Decoder extends TextDecoder without ignoreBOM: true. TextDecoder removes U+FEFF from the start of a decode. This decoder also splits a buffer on a lone surrogate and decodes the following bytes as a new segment, so the same character is removed there.

A string or template value that starts with U+FEFF, or that has U+FEFF immediately after a lone surrogate, comes back from the API without that character. A U+FEFF in the middle of a segment stays. The input in the report has no file-level BOM. The Go filesystem reader already strips a UTF-8 BOM from source text before the compiler sees the file. This default restores the character inside payload text.

The WASM file decoder already constructed Wtf8Decoder with { ignoreBOM: true }. The constructor now defaults ignoreBOM to true. An explicit ignoreBOM: false still opts out.

The new test in packages/typescript/test/wtf8.test.ts covers a leading U+FEFF, a value that is only U+FEFF, U+FEFF after a lone surrogate, a middle U+FEFF, and the template value from the report.

node --conditions=@typescript/source --test ./test/wtf8.test.ts passed, 8 tests.

I also ran the report's async API script on [email protected]. Before the change the code points were leading ["78"], only [], afterSurrogate ["d800"], middle ["61","feff","62"], template ["74","61","69","6c"]. With this constructor on that package's decoder, they are leading ["feff","78"], only ["feff"], afterSurrogate ["d800","feff"], middle ["61","feff","62"], template ["feff","74","61","69","6c"]. Node 22.19 cannot parse using in the local API sources, so that run used the published package. npx hereby test, npx hereby lint, and npx hereby check:format were not run. The issue has no Backlog milestone.

Drafted with assistance from Grok. I reviewed the diff and ran those tests.