Preventing SPM package from exposing its dependencies?

Is there a way to prevent a Swift Package Manager package from exposing its own dependencies to the applications that use the package?

Here's current observed behavior:
  • PackageA, a Swift static library (no framework, just source files)

    • This contains an SPM dependency declared in its Package.swift manifest: PackageB, a static library (no framework, just source files)

  • In Xcode, in a Application .xcproject, PackageA gets added as a dependency through the Swift Package Manager via its GitHub repo URL

    • *.swift source files do not see any of LibraryA or LibraryB contents until they are imported (which is normal)

    • As soon as you import PackageA in a *.swift file, both PackageA and PackageB are exposed in that scope (this is undesirable)

My expectation would be that only PackageA's methods and objects be exposed to the Application by default and not also expose all of its dependencies. I would expect the methods in PackageB would only be exposed if the Application also imports PackageB explicitly in a *.swift file's scope.

Is there a way to prevent LibraryB from being imported when only import LibraryA is used?

(What makes this additionally confounding is that if you open the LibraryA package itself in Xcode, LibraryB is only available when import LibraryB is denoted, which makes sense. However, when an application imports LibraryA, then unconditionally LibraryB is exposed to the application every time. This seems incorrect behavior.)
Answered by orchetect in 655846022
From the swift.org forums, this solution was presented:

Inside of PackageA, replace all
import PackageB
with
@_implementationOnly import PackageB

There may be some side-effects, but so far it has worked exactly as desired in several different scenarios.
Accepted Answer
From the swift.org forums, this solution was presented:

Inside of PackageA, replace all
import PackageB
with
@_implementationOnly import PackageB

There may be some side-effects, but so far it has worked exactly as desired in several different scenarios.
Preventing SPM package from exposing its dependencies?
 
 
Q