DioxusLabs / DioxusLabs/dioxus

cli: `[web.wasm_opt] keep_names = true` does not keep the wasm name section in release builds

Open
#5,706 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
39.1k
Forks
1.9k
Avg merge
4d 10h
Merged PRs (30d)
4

Description

## Problem

Setting `keep_names = true` in `Dioxus.toml` `[web.wasm_opt]` has no observable effect on a 0.7.9 release web build: the shipped `.wasm` still has its name section stripped (a ~5-byte stub instead of the expected several hundred KB for a ~2 MB module). This makes function-level size attribution (twiggy & friends) and readable production stack traces impossible via the documented knob.

## Reproduction

dioxus-cli 0.7.9, `dioxus = { version = "0.7", features = ["web"] }`, Rust 1.97.

`Dioxus.toml`:

```toml
[application]
name = "web"

[web.app]
title = "…"

[web.wasm_opt]
keep_names = true
```

Two builds tried:

1. `dx build --release --debug-symbols false` + `keep_names = true` → shipped wasm 2 065 315 B, twiggy shows only unnamed `code[N]` items ("function names" subsection absent).
2. `dx build --release` (debug-symbols default true) + `keep_names = true` → shipped wasm 2 069 084 B (+3.7 KB — not a name section, which for this module is ~726 KB), still only `code[N]`, no names.

Control: the pre-bindgen `cargo build --release --target wasm32-unknown-unknown` artifact of the same workspace has a proper 726 245 B "function names" subsection, so the names exist before the dx pipeline and are removed somewhere in wasm-bindgen/wasm-opt post-processing despite `keep_names = true`.

For contrast, `WasmOptConfig.level` from the same section IS honored (verified separately), so the section itself is being read.

## Expected

`keep_names = true` produces a `.wasm` with the name section intact (docs describe it as keeping names for debugging at a size cost), or the docs/config note what else is required to make it effective.

## Environment

- dioxus / dioxus-cli 0.7.9
- binaryen version_129 (auto-installed by dx), wasm-opt completed successfully in both builds (no errors in the log)
- rustc 1.97, `wasm32-unknown-unknown`, Docker `rust:1.97-slim-trixie`, linux/arm64

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reproducing the two `dx build --release` cases with `keep_names = true`, then compare their shipped `.wasm` output with the pre-bindgen `cargo build --release --target wasm32-unknown-unknown` artifact. Trace the wasm-bindgen and wasm-opt post-processing described in the report, and verify completion when the shipped module retains its name section or the configuration and documentation clearly explain the required conditions.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust, wasm
Domain
build-system, web-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.