Overview

We ran into a build failure when using the BridgeJS build plugin on a target that contains a .docc documentation catalog:

error: Error Domain=NSCocoaErrorDomain Code=256 "The file "Documentation.docc" couldn't be opened."
UserInfo={NSFilePath=.../XXX/YYY/Documentation.docc,
NSUnderlyingError=... {Error Domain=NSPOSIXErrorDomain Code=21 "Is a directory"}}

SwiftPM's target.sourceFiles includes .docc catalog entries, which the build plugin passes to BridgeJSTool as positional arguments. The tool then tries to String(contentsOf:) the directory path and fails.

Previously export subcommand had a guard sourceURL.pathExtension == "swift" else { continue } check that was dropped during the refactor to the unified generate subcommand in #499.

Fix

Rather than restoring the .swift extension filter (which could be too restrictive if the tool needs to process non-.swift files in the future), this adds a directory check to skip entries that aren't regular files.

On nested folders: This won't break nested source directories. SwiftPM's target.sourceFiles passes individual file paths (e.g., ManualBindings/Foo.swift), not subdirectory paths. The only entries that come through as directories are special bundles like .docc catalogs - regular nested source folders workfine because their contents are enumerated as individual files.

This is the minimal change that unblocks us - happy to adjust the approach if you'd prefer a different solution (like filtering in the build plugin instead), as long as .docc directories don't break the build 🙏🏻