trunk: "Cargo artifacts not found for target crate" probably caused by crate in a workspace

Since 0.17, trunk cannot build this project anymore:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />

    <!-- Trunk build setup -->
    <link data-trunk rel="css" href="normalize.css" />
    <link data-trunk rel="css" href="skeleton.css" />
    <link data-trunk rel="css" href="main.css" />
    <link data-trunk rel="copy-dir" href="fonts" />
    <!-- https://github.com/thedodd/trunk/Yak stack/3#issuecomment-698849526 -->
    <!-- Even though plain scripts are documented to just work, that's not actually the case. -->
    <link data-trunk rel="copy-file" href="./index.js" />

    <!-- THIS DOESN'T WORK: -->
    <link data-trunk rel="rust" href="." />
    <base data-trunk-public-url />
  </head>
  <body>

  </body>
</html>

Trunk invokes cargo correctly, building a wasm binary, but then seems unable to find that binary:

$ cd web-project && trunk -v build --dist ../site --release --features wee_alloc --no-default-features --public-url some-public-url
2023-07-19T17:42:40.045536Z  INFO  starting build
2023-07-19T17:42:40.157647Z  INFO spawning asset pipelines
2023-07-19T17:42:40.528959Z  INFO copying & hashing css path="path-to-web-project\\normalize.css"
2023-07-19T17:42:40.529000Z  INFO copying & hashing css path="path-to-web-project\\skeleton.css"
2023-07-19T17:42:40.529014Z  INFO copying & hashing css path="path-to-web-project\\main.css"
2023-07-19T17:42:40.529063Z  INFO copying directory path="path-to-web-project\\fonts"
2023-07-19T17:42:40.529131Z  INFO copying file path="path-to-web-project\\index.js"
2023-07-19T17:42:40.529185Z  INFO building web-project
2023-07-19T17:42:40.530548Z  INFO finished copying & hashing css path="path-to-web-project\\normalize.css"
2023-07-19T17:42:40.531534Z  INFO finished copying & hashing css path="path-to-web-project\\skeleton.css"
2023-07-19T17:42:40.532208Z  INFO finished copying & hashing css path="path-to-web-project\\main.css" 
2023-07-19T17:42:40.532698Z  INFO finished copying file path="path-to-web-project\\index.js"
2023-07-19T17:42:40.533860Z DEBUG cargo args args=["build", "--target=wasm32-unknown-unknown", "--manifest-path", "path-to-web-project\\Cargo.toml", "--release", "--no-default-features", "--features", "wee_alloc"]
2023-07-19T17:42:40.546914Z  INFO finished copying directory path="path-to-web-project\\fonts"
    Finished release [optimized] target(s) in 0.29s
2023-07-19T17:42:40.910688Z  INFO fetching cargo artifacts
2023-07-19T17:42:41.246927Z ERROR  error
error from HTML pipeline

Caused by:
    0: error from asset pipeline
    1: cargo artifacts not found for target crate
Error: error from HTML pipeline

Caused by:
    0: error from asset pipeline
    1: cargo artifacts not found for target crate

The index.html is located in the same folder as the Cargo.toml, therefore the href=“.” (anything else does not work, I tried). The Cargo.toml doesn’t specify a binary name, and just specifies a [lib] of type cdylib+rlib. Setting any data-bin breaks the build entirely just as a different href does. As said, the cargo invocation is 100% correct.

The crate that trunk builds is part of a workspace, and it lives in a direct sub-folder of the workspace. Maybe that’s related?

This issue is observable on Windows, Debian, and Ubuntu under GitHub Actions CI.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 16 (4 by maintainers)

Most upvoted comments

I encountered the same issue after updating from 0.16.0. The following change included in the current release is looking for “bin” from Cargo: https://github.com/thedodd/trunk/pull/476/files.

In my case, I just switched the project from a library to binary to fix (also can remove the #[wasm_bindgen(start)] entrypoint). It looks like Trunk, unlike wasm-pack, doesn’t require it to be a library. The Trunk documentation even states: “The easiest way to ensure that your application launches properly is to setup your app as an executable with a standard main function” (https://trunkrs.dev/).

I closed this because it appears to be related to Trunk not working with a cargo workspace. If a more thorough diagnostic is needed, folks are more than welcome to continue the discussion here. Once a solution is identified, we (folks in this thread) will need to determine if the fix will indeed be a fix in the correct direction.

Please keep me posted. Thx