Overview

The bjs_*_wrap functions generated in addImports reference class names directly:

importObject["Module"]["bjs_Greeter_wrap"] = function(pointer) {
    const obj = Greeter.__construct(pointer);  // Greeter not defined in this scope
    return swift.memory.retain(obj);
};

These classes are defined later inside createExports, so Greeter isn't in scope when addImports runs. It works at runtime because the callback only executes after createExports has been called, but it's a static scope violation - any linter with no-undef enabled will flag it, and it's flagged by default in most ESLint configs. We hit this when linting vendored BridgeJS output downstream.

The codebase already handles this elsewhere. JSGlueGen.swift has a hasDirectAccessToSwiftClass flag that controls whether to use the class directly or go through _exports['ClassName']. The import-side functions in addImports don't have direct access, so they should use the indirect lookup - same as the other import-side references already do (e.g. bjs_jsRoundTripGreeter on the same snapshot file already uses _exports['Greeter'].__construct()).

Before (SwiftClass.js snapshot):

// addImports scope - class not defined here
importObject["TestModule"]["bjs_Greeter_wrap"] = function(pointer) {
    const obj = Greeter.__construct(pointer);
    ...
};

// also addImports scope - already uses _exports correctly
let ret = imports.jsRoundTripGreeter(_exports['Greeter'].__construct(greeter));

After:

importObject["TestModule"]["bjs_Greeter_wrap"] = function(pointer) {
    const obj = _exports['Greeter'].__construct(pointer);
    ...
};