microsoft/vscode

Why this matters

microsoft/vscode is the most-watched OSS desktop application on GitHub (~160k stars), and the case study with the highest direct apples-to-apples comparison surface alint has competed against in any case study to date: the repo literally ships a custom hygiene-check script (build/hygiene.ts) that does exactly what alint is designed to do.

The vscode case study answers the question every adopter asks: “What would it look like if I rewrote my hand-rolled hygiene script as alint rules?” The answer here is concrete and verifiable: 6 of 8 stages port cleanly; the remaining 2 either need new primitives or stay in the script.

Headline catch

alint is what build/hygiene.ts would look like as a tool, not a per-repo script.

vscode’s 335-line bespoke hygiene pipeline runs 8 distinct checks. alint covers 6 of those 8 declaratively — productJson gating, copyright headers across src/ and the public extension API surface, line-endings discipline, and the cross-file copilot/engines version invariant — verified against the live tree. The remaining 2 (TS-printer round-trip; the per-line // allow-any-unicode-next-line escape-hatch unicode stream) belong in a custom script, and shell out via command:.

If alint can replace 75% of what the most-watched developer-tools repo on GitHub maintains as a 335-line custom hygiene script, it can replace most of yours too.

Where alint earns its keep here

• The most direct apples-to-apples target alint has competed against. vscode has one concentrated hygiene script. Any reader can audit build/hygiene.ts in 5 minutes and check the coverage claim against the alint config side by side.
• 45 in-tree custom eslint rules under .eslint-plugin-local/ stay where they are. This is the textbook demonstration of the “alint and eslint are non-overlapping by design” boundary — every single one is a TSESTree visitor, and every single one is correctly placed. The vscode case study strengthens the “complementary, not competing” framing rather than confusing it.
• Net-new enforcement on the public extension API surface. The 171 vscode.proposed.<name>.d.ts filename grammar is one of the highest-impact load-bearing conventions in OSS — millions of marketplace extensions depend on it — and is enforced statically by exactly nothing upstream. alint catching a typo at PR time is a genuinely net-new check.
• The Component Governance triple is asserted as files at rest. cglicenses.json + cgmanifest.json + ThirdPartyNotices.txt (3,803 lines) — alint asserts the on-disk file is present and non-trivial, catching the failure mode where a Component Governance run leaves a 0-byte stub.
• Caught real drift in the live tree. 105 unpinned third-party actions (the bundled ci/github-actions@v1 ruleset enforces the same gate Scorecard runs nightly, but at PR time); 1 real .bat/.cmd line-endings drift; 2 legitimate copyright-header violations.

Future story angles

• The cross_file_value_equals rule kind — motivated here by checkCopilotEnginesVersion (the value at $.engines.vscode in extensions/copilot/package.json must equal ^${rootPkg.version} from the root package.json) — is now a v0.10 ship-target with 10 sources past saturation. vscode is the most consumer-facing of those 10: downstream extension installs break on a version mismatch.
• Two NEW rule-knob candidates surfaced uniquely by vscode: indent_style.skip_block_comment_continuation (JSDoc ^[\t]* \* carve-out) and file_is_ascii.{allow, skip_per_line_marker} (the curated Unicode allowlist + // allow-any-unicode-next-line pragma). Niche enough that the recommended path is to keep these in build/hygiene.ts and shell out — but a credible v0.10+ refinement if more sources demand them.
• A third NEW candidate, file_content_matches_or_marker, surfaces from the 32-of-171 “placeholder proposals” pattern in vscode-dts/ (proposals that gate non-TS surface and intentionally have no declare module 'vscode' line). vscode-only today, logged as low-priority.