Skip to content

Never report diagnostics for .d.bs typedef files - #1759

Open
markwpearce wants to merge 2 commits into
v1from
fix/1757-typedef-diagnostics
Open

Never report diagnostics for .d.bs typedef files#1759
markwpearce wants to merge 2 commits into
v1from
fix/1757-typedef-diagnostics

Conversation

@markwpearce

Copy link
Copy Markdown
Collaborator

Summary

  • .d.bs files are ambient type declarations only — they're never executed, so their own content should never surface diagnostics (similar to how TypeScript's skipLibCheck treats .d.ts files).
  • Skips scope-level per-file validation (ScopeValidator) entirely for typedef files, so cross-namespace type resolution issues (e.g. cannot-find-name) inside a .d.bs no longer break a consuming project's build.
  • Also excludes typedef files from CrossScopeValidator's required-symbol collection, so their own unresolved type references aren't flagged as missing symbols. Symbols provided by .d.bs files (needed by consumers) are unaffected.

Fixes #1757

Test plan

  • Added a test reproducing the ropm-style mis-qualified .d.bs scenario from the issue (namespace-qualified ambient types that don't actually resolve) and asserting zero diagnostics
  • npm run test:nocover — full suite passes (4262 passing)
  • npm run lint passes

.d.bs files are ambient type declarations only - they're never executed,
so validating their own content (e.g. cross-scope type resolution) can
surface false errors when a typedef ends up malformed by some external
tool (e.g. ropm's namespace rewriting), even though nothing would ever
break at runtime.

Fixes #1757

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@markwpearce markwpearce added this to the v1.0.0 milestone Jul 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant