`build` command unsuable due to naming issues

[DenuxPlays]

When I run cargo leptos build I get the following output (debug and release):

But since leptos tries to load crate-name.wasm and not crate-name.something.wasm it cannot find the desired resource and the website is broken.

(cargo-leptos 0.2.10) (leptos 0.6.7)

Current workarounds:

1. (Recommended):

   [package.metadata.leptos]
   # ...
   frontend-files-content-hashes = false

2. Execute this script before launching (for example inside your dockerfile)

   find target/site/pkg -type f -exec sh -c 'filename="$1"; ext="${filename##*.}"; base="${filename%.*}"; mv "$filename" "${base%%.*}.$ext"' _ {} \;

[gbj]

I can reproduce this.

Hashes are only be added if frontend_files_content_hashes is set

https://github.com/leptos-rs/cargo-leptos/blob/270fa55bceebe968f3eca0a5d2cc3d089f61c3f4/src/command/build.rs#L67-L69

And this defaults to true

https://github.com/leptos-rs/cargo-leptos/blob/270fa55bceebe968f3eca0a5d2cc3d089f61c3f4/src/config/project.rs#L397-L399

Setting the following in your Cargo.toml will therefore disable this feature

[package.metadata.leptos]
# ...
frontend-files-content-hashes = false

@maccesch What is the intended way to serve the files correctly, given that they're now hashed?

[benwis]

There is a PR to make leptos automatically change those, here: https://github.com/leptos-rs/leptos/pull/2373/files I suspect it's got a bug in it though, and should probably use an env var instead of a file. I'll take a look and clean it up this weekend

[gbj]

It might be helpful to have more information regarding the original report actually.

If I create a new project with the latest version of cargo-leptos, and run cargo leptos build and then execute target/site/WHATEVER, it does hash the file names, but it correctly serves the files, with leptos 0.6.7.

@DenuxPlays Is the issue that you are using a Dockerfile or something similar to copy the files from target/site/pkg? Or what are the steps you're using to run it that it is serving the wrong files?

We probably should not enable this by default, because it breaks existing build scripts/Dockerfiles people have and that we share in the docs.

[kjuulh]

I have leptos 0.6.7 enabled, and with the latest cargo-leptos it broke my docker image. The files were placed correctly, but was unable to be served by leptos. Setting the frontend-files-content-hashes = false, fixed the issue without any other updates.

[DenuxPlays]

updated my issue body to show the second "work-around"

[benwis]

I have changed the hash option to default to false, and simplified the options. If you want to enable it, the setting is hash_files=true. Thanks for bringing this to our attention!