BridgeJS: Include pluginGeneratedSources in build plugin input files

[krodak]

Overview

BridgeJS wasn't seeing Swift files generated by other build plugins on the same target. If plugin A generates @JS-annotated .swift files, BridgeJS (running as plugin B) wouldn't process them because it only looked at target.sourceFiles.

Since tools-version 6.0, SPM provides target.pluginGeneratedSources - a list of output files declared by previously-run plugins on the same target. Plugin ordering follows declaration order in the plugins: array, so this is deterministic.

This change makes BridgeJS include pluginGeneratedSources in both its inputFiles (for SPM dependency tracking) and the file list passed to BridgeJSTool for skeleton scanning.

[kateinoigakukun]

Hmm, I'm not confident that it works properly with incremental builds.

Given that BridgeJSBuildPlugin is executed during a build planning stage, plugin A, generating @JS macros, still hasn't generated files. So at this stage, recursivelyCollectSwiftFiles cannot find files for the initial clean build, and it will result in not detecting changes for the additional files in the next builds.

[krodak]

Thanks for calling this out, jumped to conclusion a bit too quickly seeing it work in test runs 😅

Do you think this approach be viable?

• Keep additionalSourceDirs for file discovery.
• Add a new config field in BridgeJS, something like additionalDependencyPaths.
• In BridgeJSBuildPlugin, include those dependency paths as explicit inputFiles (alongside recursively discovered Swift files).
• In Plugin A, emit a stable marker/manifest file in its output directory (for example .bridgejs-ready) and update it whenever generated wrappers change.
• Point additionalDependencyPaths to that marker file.

My understanding is this would create an explicit "producer -> consumer" edge in the build graph, so BridgeJS should wait for plugin A output on clean build and also invalidates reliably on incremental changes?

On the other hand I understand this is quite specific usecase, if there is no much value in it in overall I can keep it within our fork 🙏🏻

[krodak]

@kateinoigakukun after some exploration, I think there might be better approach that drops additionalSourceDirs entirely.

SPM already has pluginGeneratedSources on SourceModuleTarget since tools-version 6.0. When multiple plugins are applied to the same target, later plugins receive the declared outputFiles from earlier plugins through this property. Ordering follows the plugins: array in the manifest.

/// The file URLs of any sources generated by other plugins applied
/// to the given target before the plugin being executed.
///
/// Note: Plugins are applied in order of declaration in the package
/// manifest.
@available(_PackageDescription, introduced: 6.0)
var pluginGeneratedSources: [URL] { get }

In our setup, plugin A is declared before BridgeJS in the plugins: array and declares its *Bridged.swift files as explicit outputFiles. So BridgeJS should be able to pick those up from target.pluginGeneratedSources without any config file changes.

So update to BridgeJS side would be roughly:

// After collecting inputSwiftFiles from target.sourceFiles:
let pluginGenerated = target.pluginGeneratedSources.filter {
    $0.pathExtension == "swift"
}
inputFiles.append(contentsOf: pluginGenerated)

And pass them as arguments to BridgeJSTool alongside existing source files.

This handles incremental builds properly since the files are tracked as inputFiles through SPM's own dependency system, so no config, no directory scanning. I'll update the PR if you think this is the right direction.

[kateinoigakukun]

@krodak Thanks for exploring more! pluginGeneratedSources approach looks the best for me!