You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Port the upstream suite-unicode-bom Rslint E2E #42
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.
Activity