v1: Diagnostics should never be reported for .d.bs typedef files

[markwpearce]

Summary

.d.bs files are pure ambient type declarations — they're never executed, only consumed for type-checking/IntelliSense by a downstream project (via emitDefinitions: true output, or hand-written typedefs). bsc --validate should never surface diagnostics sourced from a .d.bs file's own content.

This was previously raised in #1446 ("d.bs files with errors", closed 2025-04-10) with a maintainer comment agreeing:

I think if this is proper format for d.bs files we should have a list of validations that are not run [for] those kinds of files.

...but no fix appears to have landed, and the issue was closed without one. Filing fresh with a concrete, reproducible real-world example.

Repro

While testing whether a real BrighterScript-namespaced ropm package (brighterscript-game-engine, a game engine wrapping everything in a single namespace BGE) could actually be consumed via ropm install end-to-end, I found the emitted .d.bs typedefs are perfectly valid before ropm touches them:

namespace BGE
    function TexturePacker_GetRegions(atlas as dynamic, bitmap as ifDraw2d) as roAssociativeArray
    end function
    sub DrawCircleOutline(draw2d as ifDraw2d, line_count as integer, x as float, y as float, radius as float, rgba as integer)
    end sub
end namespace

ifDraw2d and roAssociativeArray here are global ambient Roku SDK interfaces, correctly left unqualified even though the declarations live inside namespace BGE.

After ropm install copies this package into a consumer project (applying its own namespace-prefixing rewrite, brighterscriptgameengine in this case — this specific mis-qualification is being reported separately against ropm itself, since it incorrectly namespace-qualifies these bare ambient types), the .d.bs ends up like this:

namespace brighterscriptgameengine.BGE
    function TexturePacker_GetRegions(atlas as dynamic, bitmap as brighterscriptgameengine.BGE.ifDraw2d) as brighterscriptgameengine.BGE.roAssociativeArray
    end function
end namespace

Running bsc --validate in the consumer project then throws real, build-breaking errors sourced entirely from this .d.bs file:

src/source/roku_modules/brighterscriptgameengine/utils/utils.d.bs:3:96 - error cannot-find-name: Cannot find name 'ifDraw2d' for namespace 'brighterscriptgameengine.BGE'
src/source/roku_modules/brighterscriptgameengine/utils/utils.d.bs:3:138 - error cannot-find-name: Cannot find name 'roAssociativeArray' for namespace 'brighterscriptgameengine.BGE'

...multiplied across every .d.bs file in the package (~520 such errors total in this real test), even though — per the original point in #1446 — none of this code ever actually runs.

Ask

Regardless of how a .d.bs file ends up with content that doesn't semantically resolve (a bug in some rewriting tool, a hand-authored mistake, whatever), bsc --validate should not fail a consuming project's build because of it. Treat .d.bs files as trusted/ambient — similar to how TypeScript never type-checks the content of a consumed .d.ts file the same way it checks real source.

Environment

• brighterscript@^1.0.0-alpha.50
• ropm@^0.11.9 (for reproducing the exact scenario above, though the ask here is independent of ropm)

[TwitchBronBron]

Just a point of clarification on this: typescript DOES fail consumer builds whenever there are syntax issues in the .d.ts file.

But yeah, at least in the default case, it looks like type errors in d.ts files aren't going to block the build.