* it works! * fix wasm hotpatch error * bump wasmopt * rename wasmopt flag * rename ldd_keep_exports * add build profiling * undo bundle ignore * some cleanups * more cleanups * wip: hoist up telemetry to builder * fix compile * wip: flamegraph rewrite * clean up flamegraph impl * cleanup profiling engine * add comment on spans obj * cleanup more phases * more cleanup * small cleanups * bit more cleanups * cleanup phases * sign with tokio, not std proc * split out the specific platform helpers * cleanup a bit * more cleanups * more cleanups * more cleanups * more cleanups * pull out fingerprint logic * wip... I think I have a slightly better approach. saving checkpoint * hm I think it's better now? * fix: also seems to work not in workspace mode juuust yet * okay yay almost there * clooose but not there yet * fix: manually export __wasm_apply_data_relocs since got relocations weren't firing WASM workspace hotpatching: export __wasm_apply_global_relocs to fix call_indirect type mismatch When workspace crates are recompiled with -Crelocation-model=pic for hotpatching, wasm-ld generates GOT.func.internal globals that hold element-segment-relative offsets (e.g., MetricCardProps::memoize = 31). These need __table_base added at runtime by __wasm_apply_global_relocs to become absolute table indices. wasm-ld generates __wasm_apply_global_relocs but treats it as an internal synthetic function -- neither --export nor --export-if-defined will export it. Without the export, the runtime's call silently failed (the old code used unchecked_into on undefined), leaving the globals unrelocated. Function pointers then pointed to index 31 in the original module's table (some unrelated function) instead of table_base + 31 (the patched function), causing call_indirect to a signature that does not match. Three changes: patch.rs: After walrus processing, find __wasm_apply_global_relocs by name and add it as an export before emitting the patched wasm. lib.rs: Replace unchecked_into with dyn_into for calling relocation functions, so missing exports are handled gracefully instead of silently swallowed. link.rs: Remove the ineffective --export-if-defined flags that were added during debugging. * cleanup * fix scope dir * change up naming a bit * more tidying up * more cleanups * ignore early return * clean er up * more comprehensive cache bustign * bust fingerprints of dag * move bust_fingerprint back to request.rs * add better rustdoc * more idiomatic * more cleanups * fix panic, typos * more lints * only delete workspace prints in fat mod * clippy
📦✨ Dioxus CLI
Tooling to supercharge Dioxus projects
The dioxus-cli (inspired by wasm-pack and webpack) is a tool for getting Dioxus projects up and running. It handles building, bundling, development and publishing to simplify development.
Installation
Install the stable version (recommended)
cargo install dioxus-cli
Install the latest development build through git
To get the latest bug fixes and features, you can install the development version from git. However, this is not fully tested. That means you're probably going to have more bugs despite having the latest bug fixes.
cargo install --git https://github.com/DioxusLabs/dioxus dioxus-cli
This will download the CLI from the master branch,
and install it in Cargo's global binary directory (~/.cargo/bin/ by default).
Install from local folder
Note: The CLI will fail to build projects in debug profile. This is currently under investigation.
cargo install --path .
Get started
Use dx new to initialize a new Dioxus project.
It will be cloned from the dioxus-template repository.
Alternatively, you can specify the template path:
dx new --template gh:dioxuslabs/dioxus-template
Run dx --help for a list of all the available commands.
Furthermore, you can run dx <command> --help to get help with a specific command.
Dioxus config file
You can use the Dioxus.toml file for further configuration.
Some fields are mandatory, but the CLI tool will tell you which ones are missing.
You can create a Dioxus.toml with all fields already set using dx config init project-name,
or you can use this bare-bones template (only mandatory fields) to get started:
[application]
name = "project-name"
# Currently supported platforms: web, desktop
default_platform = "web"
# Optional: enable copying from a static directory (e.g. "public")
public_dir = "public"
[web.app]
title = "Hello"
[web.resource.dev]