Trunk v0.18.0 detects multiple binary crates and ignores data-bin link

[MeoMix]

Hi

My GitHub workflow action automatically updated to use the latest version of Trunk yesterday and build stopped working.

I believe this is because my Cargo.toml looks like:

[package]
name = "symbiants_pkg"
version = "0.1.0"
edition = "2021"
build = "build.rs"

[lib]
name = "symbiants_lib"
crate-type = ["cdylib", "rlib"]

and a recent change to Trunk introduced detection for cdylib targets.

In response, I made the following change to my index.html: MeoMix/symbiants@c484abd

but builds continue to fail. I'm also able to reproduce this locally.

If I edit the code from <link data-trunk rel="rust" data-bin="symbiants_pkg" /> to <link data-trunk rel="rust" data-bin="symbiants" />

then I see the error output change:

error: no bin target named `symbiants`.
Available bin targets:
    symbiants_pkg

So it's clear to me that index.html is being parsed and symbiants_pkg is known to the Trunk build process, but that the explicit data-bin declaration is insufficient to eliminate the build ambiguity error.

The error is:

warning: `symbiants_pkg` (lib) generated 15 warnings (run `cargo fix --lib -p symbiants_pkg` to apply 4 suggestions)
    Finished dev [optimized + debuginfo] target(s) in 0.19s
2023-12-13T03:00:36.724955Z  INFO fetching cargo artifacts
2023-12-13T03:00:36.995951Z ERROR ❌ error
error from build pipeline

Caused by:
    0: error from asset pipeline
    1: found more than one binary crate: ["symbiants_lib", "symbiants_pkg"], consider adding `<link data-trunk rel="rust" data-bin={bin} />` to the index.html
Error: error from build pipeline

I will try to put together a minimal repo soon.

EDIT: https://github.com/MeoMix/trunk_broken_example

[vgwidt]

Ah yeah it makes sense that this is happening because of the if bin_artifacts.len() > 1 condition since it is detecting two "binary" artifacts with the same manifest identifer. Also the reason you see "symbiants_pkg" as the only available binary target is because using data-bin passes --bin to cargo, which is returning that message.

Adding a check to see if the data-bin is specified and ensuring the specified data-bin name matches the artifact name fixed this for me when testing.

Unlike previous Trunk versions, your example will not build with this fix unless you specify the data-bin attribute properly. In 0.17 it would have worked correctly because it was filtering for "bin". I'm not sure which artifact would have been selected in 0.16 though.

I want to do more testing before making a PR but @ctron please feel free to make the necessary fixes as I may not get to it right away.

Branch with fix is here: https://github.com/vgwidt/trunk/tree/fix-multiple-binaries-detected

[ctron]

Ok, this is trickier than anticipated. I gave it a try, and ended up with the same fix.

That fixes this issue indeed, but doesn't completely fix the issue for the cdylib case. Because now it ties together the --bin argument with the filter for that target. So if there are multiple targets, then filtering using the data-bin will work for binaries, but break cdylib cases, as those require --lib (or at least not bin) when running cargo.

We could add a data-lib attribute as well. But that might conflict with a data-bin attribute. So we need a new check there. Maybe it makes more sense to have a data-target-name attribute?

But yes, I think we found the issue. The question is just how solve this without breaking something (again). I will take a look at this tomorrow.