Problem
The standalone rslint extension's suite-unicode-bom E2E was never ported. Every other functional upstream suite has a counterpart under packages/vscode/e2e/lint/; this one is missing, so the worker/proxy layer this extension adds between VS Code and the Go server has no coverage for the BOM boundary case.
Upstream source: rslint@origin/main:packages/vscode-extension/__tests__/suite-unicode-bom/unicode-bom.test.ts and __tests__/fixtures-unicode-bom/. Added in web-infra-dev/rslint#1560 (port of the unicode-bom rule, 2026-08-06), fixture moved from rslint.json to a native config in web-infra-dev/rslint#1951. #26 ported #1611 and #1279 but skipped #1560.
What the upstream test guards
VS Code consumes a UTF-8 BOM as encoding metadata, so the document model sent over LSP contains no U+FEFF even though the file bytes start with EF BB BF. The unicode-bom rule once emitted a BOM-removal fix with range [-1, 0], which cannot be expressed as a VS Code TextEdit; the final fix skips the rule for editor linting and leaves BOM fixes to the CLI (internal/lsp/lint_generation.go:20-39). The test asserts:
- disk starts with
EF BB BF, TextDocument.getText() has no U+FEFF;
- diagnostics contain
no-var (positive control) and nothing from unicode-bom;
- whole-document Quick Fixes contain
Disable no-var for this line and no BOM-related action;
- document text and dirty state are unchanged.
Why it still matters here
Static reading says this extension is transparent: the router only gates by runtime ownership (stacks/lint/WorkspaceDocumentRouter.ts:101-176), vscode-languageclient serializes getText() and forwards UTF-16 incremental ranges unchanged, and the worker forwards requests without rewriting text or positions (stacks/lint/worker/index.ts:109-166,219-241). The existing emoji test (e2e/lint/suite/extension.test.ts:388-448) proves UTF-16 incremental alignment, not BOM handling. That is reasoning, not evidence; E2E is the ground truth for editor behavior in this repo.
Proposal
Port suite-unicode-bom and its fixture into packages/vscode/e2e/lint/ as-is (native rslint.config.mjs enabling unicode-bom and no-var, per the post-#1951 shape), register it in e2e/run.mjs, and run pnpm test:e2e:lint.
Problem
The standalone rslint extension's
suite-unicode-bomE2E was never ported. Every other functional upstream suite has a counterpart underpackages/vscode/e2e/lint/; this one is missing, so the worker/proxy layer this extension adds between VS Code and the Go server has no coverage for the BOM boundary case.Upstream source:
rslint@origin/main:packages/vscode-extension/__tests__/suite-unicode-bom/unicode-bom.test.tsand__tests__/fixtures-unicode-bom/. Added in web-infra-dev/rslint#1560 (port of theunicode-bomrule, 2026-08-06), fixture moved fromrslint.jsonto a native config in web-infra-dev/rslint#1951. #26 ported #1611 and #1279 but skipped #1560.What the upstream test guards
VS Code consumes a UTF-8 BOM as encoding metadata, so the document model sent over LSP contains no U+FEFF even though the file bytes start with
EF BB BF. Theunicode-bomrule once emitted a BOM-removal fix with range[-1, 0], which cannot be expressed as a VS CodeTextEdit; the final fix skips the rule for editor linting and leaves BOM fixes to the CLI (internal/lsp/lint_generation.go:20-39). The test asserts:EF BB BF,TextDocument.getText()has no U+FEFF;no-var(positive control) and nothing fromunicode-bom;Disable no-var for this lineand no BOM-related action;Why it still matters here
Static reading says this extension is transparent: the router only gates by runtime ownership (
stacks/lint/WorkspaceDocumentRouter.ts:101-176),vscode-languageclientserializesgetText()and forwards UTF-16 incremental ranges unchanged, and the worker forwards requests without rewriting text or positions (stacks/lint/worker/index.ts:109-166,219-241). The existing emoji test (e2e/lint/suite/extension.test.ts:388-448) proves UTF-16 incremental alignment, not BOM handling. That is reasoning, not evidence; E2E is the ground truth for editor behavior in this repo.Proposal
Port
suite-unicode-bomand its fixture intopackages/vscode/e2e/lint/as-is (nativerslint.config.mjsenablingunicode-bomandno-var, per the post-#1951 shape), register it ine2e/run.mjs, and runpnpm test:e2e:lint.