Transitive dependencies not working after Tuist update

Troubleshooting & how to
1

Hi!

I’m using an architecture where all third-party dependencies are declared in a separate target called ExternalDependencies. This target is static, and it’s added as a dependency to all feature targets (which are also static). This setup used to work fine, but after updating Tuist, the project no longer builds.

It seems that transitive dependencies are no longer automatically propagated — for example, if ExternalDependencies includes .product(name: “FirebaseCore”, package: “firebase-ios-sdk”), then a feature target that depends on ExternalDependencies no longer sees FirebaseCore, even if it uses its API.

I’d like to keep the architecture where dependencies are declared in a single place. Is there a way to make this work without duplicating .product(…) in every feature?

Thanks!

2

Hey!

Are you using public import in the ExternalDependencies module? Publicly imported dependencies should be available in downstream targets without explicitly depending on those.

3

No, my ExternalDependencies target doesn’t contain any source code. It’s used only to declare all third-party dependencies in one place, so that feature targets can access all of them by depending only on ExternalDependencies.

Am I correct that, in the new version of Tuist, I need to add a source file to ExternalDependencies and use public import for all the required third-party modules, so that they are transitively available to downstream targets?

4

I think it should re-export those dependencies using public import.

I am not aware of changing anything lately that could influence this, but I would recommend using public import regardless.

5

I added a file with a public import inside the ExternalDependencies target, but I still get a linker error (Undefined symbols).

As I understand it, public import makes the types visible during compilation, but it doesn’t guarantee that the binary will be linked.

So without explicitly declaring .product(…) in the target’s dependencies, linking fails.

I don’t understand why this used to work in the previous version. Before this, I was using Tuist 4.9.0.

6

I forgot to mention: the linker error doesn’t happen for all libraries — it only occurs for certain transitive dependencies.

For example, when integrating Firebase, I get linker errors related to internal modules like GULEnvironment, GULLogger, and several others (around 7 in total).

The main modules like Firebase are linked correctly, but their transitive dependencies are not.

7

I see – that was not obvious from the initial description of the issue, I was under the impression the project was not building.

You can use xcdiff and compare the project generated with 4.9.0 and with later versions. I am not aware of anything changing that could impact this but 4.9.0 is a relatively old version, so there’s a lot that has changed since then.

It might be worth for you to figure out the exact version that broke your setup. Alternatively, having a reproducible sample would help here as well.

8

Got it — the issue appeared in the new version of Tuist: if I add the dependency via .external, I get a linker error. But if I use .package(product:), everything links correctly.

Is there a way I can fix this myself, or is it an issue on Tuist’s side? I’d like to keep using tuist install to manage dependencies — it works much more reliably and faster than the default SPM resolution.

import ProjectDescription

let project = Project(
    name: "TuistFirebaseSample",
    packages: [
        .package(url: "https://github.com/firebase/firebase-ios-sdk", from: "11.6.0")
    ],
    targets: [
        .target(
            name: "ExternalDependencies",
            destinations: .iOS,
            product: .framework,
            bundleId: "com.example.ExternalDependencies",
            sources: ["Targets/ExternalDependencies/Sources/**"],
            dependencies: [
                .external(name: "FirebasePerformance"), // linker error
                .package(product: "FirebasePerformance"), // OK!
            ]
        ),
        .target(
            name: "Feature",
            destinations: .iOS,
            product: .framework,
            bundleId: "com.example.Feature",
            sources: ["Targets/Feature/Sources/**"],
            dependencies: [
                .target(name: "ExternalDependencies")
            ]
        ),
    ]
)
9

This looks like an issue on the Tuist side then. I’d suggest creating a GitHub issue with a fully reproducible sample (not just a snippet of the project definition) and we’ll try to look into it.

As mentioned, it would be great if you could find out in which Tuist version the behavior was broken.

10