DioxusLabs / DioxusLabs/dioxus
[web.resource] writes the unhashed source path into index.html instead of the content-hashed output filename
- Dominant language
- Rust
- Stars
- 39.1k
- Forks
- 1.9k
- Avg merge
- 4d 10h
- Merged PRs (30d)
- 4
Description
## Bug report
`[web.resource]` entries in `Dioxus.toml` are correctly discovered, content-hashed, and copied into the release output's `assets/` directory — but the ``/`` tag that `dx build` writes into the generated `index.html` uses the **literal, pre-hash path** from the config, not the actual hashed output filename. The referenced asset never exists at that URL in a real build.
### Reproduction
`Dioxus.toml`:
```toml
[web.resource]
style = ["assets/styling/main.css"]
[web.resource.dev]
style = []
```
```sh
dx build --web --release --debug-symbols=false
```
### Expected
`index.html`'s `<link>` tag references the same hashed filename the asset pipeline actually produced, e.g.:
```html
<link rel="stylesheet" href="assets/main-dxh6408cdb93e84aff.css">
```
### Actual
```html
<link rel="stylesheet" href="assets/styling/main.css">
```
...while the build log confirms the file *was* processed through the normal asset-hashing pipeline:
```
INFO Copying asset (10/11): /path/to/project/assets/styling/main.css
```
and the actual output directory contains the correctly-hashed file at a different path entirely:
```
target/dx/<app>/release/web/public/assets/main-dxh6408cdb93e84aff.css
```
There is no `target/dx/<app>/release/web/public/assets/styling/` directory at all — the literal href in `index.html` 404s (or, with `not_found_handling = "single-page-application"` on Cloudflare Workers/wrangler, silently falls back to serving `index.html` itself as the "CSS", which is how we noticed this).
### Environment
- `dioxus-cli` 0.7.9 (`dx 0.7.9 (bfcc111)`)
- `dioxus` 0.7.9
- Target: `--web`, release build
- Confirmed on both a fresh `rm -rf target/dx/<app>/release` clean build and an incremental rebuild — not a stale-cache artifact.
### Why this matters
We hit this while fixing a CLS/FOUC regression: `[web.resource]` is the documented way to get a stylesheet into the static `<head>` so it loads in parallel with `app.js`/`.wasm` instead of only after a runtime `document::Link` call fires post-WASM-boot. The feature works exactly as intended *except* for this one detail, which makes it unusable as documented — the emitted `<link>` never resolves to a real file.
### Workaround (current)
We work around this by placing an *unhashed* copy of the compiled CSS at the exact literal path `dx` writes into `index.html`, via `[application].asset_dir`'s passthrough (`Dioxus.toml`'s `asset_dir = "public"` copies `public/*` verbatim into the output root) — i.e. we duplicate the file at `public/assets/styling/main.css` as a build step, so the broken literal href happens to resolve anyway. This sacrifices the whole point of content-hashing (cache-busting/immutability) for that one asset, which isn't a real fix, just a way to unblock ourselves.
Happy to put together a minimal reproduction repo if useful — we've only confirmed this in our own project so far, but nothing about the reproduction steps above looks specific to our project's structure.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start at the [web.resource] handling in dx build and trace how assets are hashed and how index.html tags are generated. Reproduce with the Dioxus.toml example and a release web build; done means each emitted link or script references the hashed file that exists in the release assets directory.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- build-system, web-dev
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100