René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Port the upstream suite-unicode-bom Rslint E2E","articleBody":"## Problem\n\nThe 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.\n\nUpstream 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. rstackjs/rstack-editor#26 ported #1611 and #1279 but skipped #1560.\n\n## What the upstream test guards\n\nVS 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:\n\n1. disk starts with `EF BB BF`, `TextDocument.getText()` has no U+FEFF;\n2. diagnostics contain `no-var` (positive control) and nothing from `unicode-bom`;\n3. whole-document Quick Fixes contain `Disable no-var for this line` and no BOM-related action;\n4. document text and dirty state are unchanged.\n\n## Why it still matters here\n\nStatic 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.\n\n## Proposal\n\nPort `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`.\n","author":{"url":"https://github.com/fi3ework","@type":"Person","name":"fi3ework"},"datePublished":"2026-09-03T08:15:00Z","url":"https://github.com/rstackjs/rstack-editor/issues/42"}