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)
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/).
ehrm…
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