bslint+rooibos-roku (together): pre-existing file can't resolve a symbol from a brand-new file

[markwpearce]

What happened

With brighterscript, @rokucommunity/bslint, and rooibos-roku all active together (as bsconfig.test.json does), adding any brand-new .bs file and referencing a symbol from it in a pre-existing file (tried Renderer.bs, Game.bs, RendererHelpers.bs) fails to compile with cannot-find-name/cannot-find-function - even for a single trivial top-level function with no namespace, no custom class, nothing but native/primitive types. The same new file resolves fine when referenced from another brand-new file, or from a Rooibos spec file. New content appended to an existing file resolves fine when referenced from other content in that same file - the boundary that breaks is specifically "old file → new file."

Reproduced on a completely fresh git clone (rules out any local cache/session state).

Versions (already aligned - not a mismatch)

All three are pinned/resolve to the same alpha generation, confirmed the latest published version of each at the time of testing:

• brighterscript 1.0.0-alpha.52
• @rokucommunity/bslint 1.0.0-alpha.52
• rooibos-roku 6.0.0-alpha.52

Repro

1. Fresh clone of this repo.
2. Add src/source/engine/AAAFreshTest.bs:

   function aaaFreshGlobalHello() as string
     return "hi"
   end function

3. Add a one-line call to it from an existing method in src/source/engine/renderer/Renderer.bs, e.g. right after class Renderer:

   function testAAAFreshGlobal() as string
     return aaaFreshGlobalHello()
   end function

4. npx bsc --project bsconfig.test.json --create-package=false -> cannot-find-function: Cannot find function 'aaaFreshGlobalHello'.

What's been ruled out

• Namespace/class name collisions (new class named the same as its own namespace) - tested, not the cause; a differently-named class fails identically.
• Custom-class-type coupling (Renderer needing to reference a new file's class as a param/return type) - tested with a function using only ifDraw2d/float/string/integer, fails identically.
• Local build cache - reproduced on a fresh clone.
• Git staging/committing the new file before editing the existing file - tried both separately-committed and everything-in-one-commit; neither fixes it.
• Using only one of the two plugins: with only @rokucommunity/bslint (no rooibos-roku), or only rooibos-roku (no bslint), the same repro compiles clean in a scratch bsconfig.json. It's a two-plugin interaction, not either plugin alone.

Practical workaround found

New-file-calls-old-file (the reverse direction) works fine - a brand-new file's function/method can call a public method on an existing class without issue. Used this for #168 (QR code rendering): instead of Renderer.drawQRCode() reaching into new BGE.QrCode.* files, BGE.QrCode.draw(renderer, ...) takes the existing Renderer instance and calls two new-but-same-file-only public methods added to Renderer.bs (getDraw2d(), incrementDrawCalls()). See PR #174.

Follow-up if this gets fixed upstream

If a future brighterscript/bslint/rooibos-roku release fixes this, it'd be worth revisiting whether BGE.QrCode should integrate more directly with Renderer - e.g. an actual Renderer.drawQRCode()/drawQRCodeTo() method (matching every other Renderer.draw* call's shape) instead of the current BGE.QrCode.draw(renderer, ...) free-function workaround.

[markwpearce]

Same root cause as #178 (its body explicitly says so), just reproduced via the bslint+rooibos-roku pairing specifically. Not an upstream brighterscript/bslint/rooibos-roku bug: this project's SceneGraph component scopes aren't ambient like source scope, so a hand-maintained "import everything" manifest had gone stale and was masking real missing imports for the old-file -> new-file direction. PR #186 (merged) fixed this with real per-file import hygiene across src/source/, confirmed via bsc --validate (zero diagnostics) and full npm run check (951/951 tests) with both bslint and rooibos-roku active per bsconfig.test.json. The repro steps in this issue no longer reproduce against current main.