bevy_cli

[small turret]

error[E0514]: found crate `bevy` compiled by an incompatible version of rustc
 --> src/main.rs:2:5
  |
2 | use bevy::{ecs::query::Has, prelude::*};
  |     ^^^^
  |
  = note: the following crate versions were found:
          crate `bevy` compiled by rustc 1.92.0-nightly (844264add 2025-10-14): /tmp/tmp.uTwD31e880/target/debug/deps/libbevy-7c197d731b9df74d.rmeta
  = help: please recompile that crate using this compiler (rustc 1.92.0-nightly (4645a7988 2025-09-17)) (consider running `cargo clean` first)

Wait, so you need to compile your project with the same compiler as bevy_lint? 😔

[pale viper]

Not usually, but you may need to run cargo clean every now and then

If you do use nightly Rust, though, it may help reduce check times and the size of your target directory if you synchronize the version!

[small turret]

Is there a reason bevy_lint is depending on a specific compiler version?

Weird I tried cargo clean and it's still giving me this error 🤔
I think it's still compiling with the version in my environment for some reason.

[small turret]

Ok I think I get the problem now. bevy_lint is correctly using the cargo from 4645a7988 2025-09-17 (I've also set BEVY_LINT_SYSROOT), but cargo itself is spawning rustc from my environment which is a different version.

While bevy lint is compiling:

$ readlink /proc/(pgrep cargo)/exe
/nix/store/18wi184p3n0xnkpapsiwka1sb32wbr40-cargo-1.92.0-nightly-2025-09-18-x86_64-unknown-linux-gnu/bin/cargo

$ readlink /proc/(pgrep rustc)/exe
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc
/nix/store/955a0iarjbyp9x9z7mpgr0bzbh8hb4a7-rust-default-1.92.0-nightly-2025-10-15/bin/rustc

The rustc version is the one from my environment and cargo is the version bevy_lint is invoking.

[limber wedge]

We are using clippy_utils and we need to match their nightly versions. The rustc internal crates are not stable so this would not work otherwise

[limber wedge]

Glad you got it to work!

[small turret]

Well, I got it to "work" by setting RUSTC manually 😅

[kindred island]

I tested it with my game, and it worked without any changes in Rust. I'll make a pr and test that it works in an empty project. Are there docs on installing a local build of bevy_cli?

[small turret]

I think the behavior when a custom sysroot is used is not completely correct here: https://github.com/TheBevyFlock/bevy_cli/blob/203cc077990b6b7c2652dd5d977cfd13860cb8f7/bevy_lint/src/bin/bevy_lint.rs#L39
RUSTC probably needs to be set so that the right version is called. I think rustup does this automatically, but on non-rustup environments you need to do it yourself.

[small turret]

I see 🤔
It's kinda annoying because you now have to choose between suffering from double compile times or suffering from being stuck with the nightly version that bevy_lint happens to use.

[limber wedge]

For the cli there is not really anything you need to get it set up locally so checking out the repo is enough to get started

[foggy basin]

The easiest way to test it out is to do cargo install --path .
Personally, I set up a small script that builds and executes the local folder under a bevy-dev alias so I can iterate a bit faster, but that's not necessary :)

[limber wedge]

https://github.com/TheBevyFlock/bevy_cli/issues/525,https://github.com/TheBevyFlock/bevy_cli/issues/524 does this mean for any lifecycle observer you should just always add Allow<Disabled>? @twilit dew And the reason is that plugin authors cannot know if their users will use Disabled components or not

[twilit dew]

More or less yeah

The reason is that lifecycle observers are IME almost always uses to define invariants

But when someone spawns something with a default filter, they would skip out on setting up those invariants

Then when the default filter is removed later, you get entity in an invalid state

Ideally this should not be just allowing Disabled, but all default filters, as the user can define their own.

But we currently have no way to express that

So at least it should allow Disabled. Last time this was discussed, where was broad agreement about this, and I PRd something the other day to Bevy itself with the same motivation

technically it should nowadays be even more boilerplate

(Allow<Disabled>, Allow<Internal>), for the rare user that likes to put components on observers

But I think this is niche enough that I would go with the slim Allow<Disabled> for bow until we have an upstream AllowAll

[limber wedge]

is there a reason this is not handled the inverse way? that AllowAll is the default?

fn on_disable(trigger: On<Add, (Disabled, Internal)>, query: Query<&Foo, (Allow<Disabled>, Allow<Internal>)>) is a bit

[twilit dew]

Well that’s the point of DEFAULT filters: they’re the default

But yes, they should be the default for observers

There’s a few proposals out there

[limber wedge]

i see i see thank you!!

[twilit dew]

They should be *ignored by default for observers, sorry

[molten merlin]

internal just got removed iirc, fwiw

https://github.com/bevyengine/bevy/pull/21623

[limber wedge]

ah nice thanks for the info

[twilit dew]

Oh wow great news!

[pale viper]

I'm not sure I fully understand what the problem is here. When you run bevy_lint, it should spawn cargo, which should then run bevy_lint_driver (not rustc)

bevy_lint_driver acts as a replacement to rustc, so running the Bevy linter should never invoke rustc

[small turret]

Yes, it's cargo that invokes rustc but it invokes it from the environment for some reason (you can check via ps that they are invoked with a non-absolute path). So I think that the more correct behavior when BEVY_LINT_SYSROOT is set here is to set the appropriate RUSTC before invoking cargo.

[small turret]

Wait that is strange. The project have to be compiled first, right?

[pale viper]

Nope! Technically speaking, bevy_lint_driver can fully compile Rust programs

[small turret]

Weird, when I run bevy lint I can see rustc running in the background...

And all the usual compile logs in the output too...

[small turret]

Like am I seeing things here, who's compiling my Rust 😂

$ bevy lint --workspace --all-targets
   Compiling proc-macro2 v1.0.94
   Compiling unicode-ident v1.0.18
   Compiling serde_core v1.0.228

[limber wedge]

i guess BD ment more invoke directly. its more like bevy_lint -> cargo -> bevy_lint_driver -> rustc (with the specific configuration that the driver sets up). correct me if im wrong @pale viper

[pale viper]

More specifically, rustc the executable links to the dynamic library librustc_driver.so, which does all the actual compiling. bevy_lint_driver also links to librustc_driver.so, and is able to do the same thing

bevy_lint_driver should not be spawning any processes beyond running cargo metadata

[limber wedge]

Im not on my pc but i thought you will see rustc processes. If you run bevy_lint —verbose you should see : <path to rust toolchain>/rustc and i guess you will see the same in top

I thought run_compiler or how the function is called will actually invoke rustc TIL

[pale viper]

So I just tested it: bevy_lint uses rustc to compile dependencies and bevy_lint_driver to compile crates in the workspace

As most projects spend their time compiler dependencies, that might be why you thought the linter always used rustc

I think this is because we use RUSTC_WORKSPACE_WRAPPER, rather than RUSTC_WRAPPER to override the Rust compiler

[limber wedge]

Yep and i nearly always run cargo clean first when testing the linter on a project

[pale viper]

build.rustc-workspace-wrapper

Sets a wrapper to execute instead of rustc, for workspace members only. When building a single-package project without workspaces, that package is considered to be the workspace. The first argument passed to the wrapper is the path to the actual executable to use (i.e., build.rustc, if that is set, or "rustc" otherwise). It affects the filename hash so that artifacts produced by the wrapper are cached separately.

https://doc.rust-lang.org/stable/cargo/reference/config.html#buildrustc-workspace-wrapper

Actually, I wonder...

If we switched to RUSTC_WRAPPER, do you think that would fix using RUSTFLAGS to configure lints?

Right now doing something like RUSTFLAGS="--deny bevy::unit_in_bundle" fails because the dependencies don't recognize the lint

But if we used RUSTC_WRAPPER, the linter would be used to compile dependencies as well. Because the linter registers bevy as a tool, it's equivalent to adding #![register_tool(bevy)] to all of the dependencies

That might mean that cargo check and bevy_lint won't share dependency artifacts, though, which might not be worth it

[limber wedge]

Would be an interesting exploration imo

But this would not mean that all lints are also run on all dependencies?

[pale viper]

Yeah, good point. We probably don't want to lint dependencies, as the user won't be able to fix any of the warnings

(Though I believe Cargo does something to silence warnings when compiling dependencies, so the user doesn't see them)

[small turret]

Hmm the problem I was having is that if your project environment is using a different Rust version than your BEVY_LINT_SYSROOT, you get the compile errors due to compatibility issues.

So in the end, I had to run RUSTC="$BEVY_LINT_SYSROOT"/bin/rustc bevy lint to make it work.

I'm nut sure how RUSTC_WRAPPER ties to all of this.

I feel that the most reasonable way to use bevy lint is to tie your project compiler to the version used by bevy_lint and that's kinda unfortunate.

[pale viper]

Yeah, I totally get that

What if the linter targeted the latest stable Rust release? Would it be easier or harder to work with?

-# We'd have to use some RUSTC_BOOTSTRAP wizardry, and would need to get rid of clippy_utils, but it technically is feasible

[limber wedge]

i love clippy_utils

[pale viper]

Hah, ditching it may be a no-go!

Though, there's a chance it would be API-compatible with the latest stable Rust release, since they're released at the same time

[limber wedge]

imo its unfortunate but not too big of an issue and in a CI environment i think its no issue at all

and i think if someone is already using nightly i dont see a big downside of using the same nightly version we use?

[limber wedge]

it has to be no? if we would use the same clippy_utils that gets shipped with the clippy for this stable toolchain

[small turret]

Well I do use nightly, just not the same version as the bevy_lint.

[small turret]

Yeah, but I wanted to use bevy_lint in my local environment with rust_analyzer: https://thebevyflock.github.io/bevy_cli/linter/rust-analyzer.html. IMO, having to push and wait for the CI just to see the lints is way too much friction for me.

[small turret]

The downside is that you may want to use a nightly version older or newer than the one bevy_lint is using.
For example, you might want to use a new fancy nightly feature, but the version is incompatible with the current bevy_lint.

[limber wedge]

Yea makes sense

[limber wedge]

There is surprisingly little documented on Trait Checking in the clippy Development guide (besides how to check if a given type implements a trait) if you have found any additional useful blogs let me know 🥺 @pale viper

[pale viper]

Check out the Rustc Dev Guide! Things may be difficult right now, though, since I think there may be 3 trait solvers currently in flight in the compiler

If you can find a Clippy lint that does something similar to what you want, I found looking at its source code is a great source of practical knowledge!

Are you working on the zst_query Has<T> issue? I tried working on it a week ago, but ran into a wall where I wasn't sure how to handle resolving the associated type. My current approach tries going through the HIR, looking for the impl QueryData for T and resolving the type of type Item, but maybe you have a better approach that goes through the type system

[limber wedge]

yea have been doing this a lot but i think that most are more "does this ty implement this trait" and that one i know how to ^^

[limber wedge]

yes if you feel like it feel free to look at the open pr i was trying some stuff out but i never felt like "this IS the right way to do it" so i wanted to read a bit more about it

[rigid bluff]

Hello, something that would really help me is a "watch" mode for bevy run web where it rebuilds whenever I save a file, similar to how other web frameworks do it.
If someone knows how this kind of thing is implemented I could try and work on it

[pale viper]

Have you tried using bacon? That, or the deprecated cargo-watch might support your needs

[limber wedge]

Tim tried some first experiments with bacon once here: https://github.com/TimJentzsch/bevy_bacon but we haven't had time to tackle this yet

[foggy basin]

If I remember correctly, it didn't work that well :D

[limber wedge]

Hahaha Thats unlucky 😂

[foggy basin]

I think the problem was that it didn't know that we also have to execute the wasm bundling after building so it didn't know when the rebuild completed
Also instead of killing the server every time we could keep the server running and instead send a reload event

Maybe https://github.com/watchexec/watchexec could be useful, it can also be used as a library

[foggy basin]

Oh actually the CLI can also be used to just emit the events as json and process them yourself. This is actually perfect for us: we get maximum flexibility without increasing the CLI binary too much

[limber wedge]

I think i used this once when writing some python

[limber wedge]

That would be really cool

If possible i would want to avoid having multiple „watch“ binaries but i guess we will see how we can integrate subsecond once they had time to split it out (if they still want to)

[rigid bluff]

Hello, I get this error on web:

bevy_kart.js:1056  GET http://localhost:4000/assets/sprites/karts.png.meta net::ERR_ABORTED 404 (Not Found)

Whenever I load a picture, like it expects a meta file everytime, i'm not sure how to get rid of it

[foggy basin]

I think there was a setting in the asset loader where you can disable loading meta files automatically

[twilit dew]

That’s a lovely logo

[pale viper]

Rust 1.91.0 is out! Here's the Rustup PR that upgrades the linter to the latest nightly: https://github.com/TheBevyFlock/bevy_cli/pull/667

I had some fun writing unit tests for the sym module! I don't usually get to write those, as the linter makes it hard to setup all the moving parts necessary to test

Happy Halloween 👻 🎃 🍬

[limber wedge]

I will be prepared for spooky jump scares in the pr

[pale viper]

Ohhhhh, no jumpscares :(

This is the best I can do in that category:

[limber wedge]

Hahha wtf

[foggy basin]

Ok this is super cool:
I finished setting up my new Desktop PC for faster compile times.
And on my laptop, I set it up to connect via tailscale, so in VS Code I can SSH into my desktop PC to use it as a build machine.
The catch: I can't actually run Bevy games, because the GUI can't be forwarded.
But wait: I can just use bevy run web and VS Code automatically forwards the port!
So now I can properly develop when I'm on the go while keeping my laptop at 2% CPU and the fans quiet, enjoying faster compile times, while still being able to see if the examples work :)

[limber wedge]

Thats so cool! Having a nice setup is just so relaxing

I love my personal setup at home

I got a bit nerdsniped and im experimenting with a watch command

[limber wedge]

If you have fast internet you could also copy the binary to your host machine

[foggy basin]

Awesome, I was itching to try that out too :D
Which setup are you trying out?

[foggy basin]

True, that could probably be automated as well

I might play around a bit more with that, especially for RustWeek next year it would come in handy.
Last time, I probably spent more than half of my time waiting for compiles haha

[limber wedge]

Hahahaha yea im pretty lucky that i still got my MacBook

[limber wedge]

I really like how Dioxus handles it so im trying out something inspired by them

So i would use notify to watch for changes

(Same crate watchexec uses under the hood)

[foggy basin]

Curious to see how it will turn out!

[limber wedge]

Same lol

[pale viper]

I love Tailscale! I use it all the time to remotely connect to the server in my room

I’m glad you got a better setup, what specs did you end up going with for the PC?

[heady fog]

Hey TIMMÄH,
been reading through some of your messages about the Bevy CLI and that remote compile setup, really slick stuff.
The tailscale + VS Code flow you described sounds like a dream for cross-device dev work.

Would love to pick your brain sometime about your workflow optimizations, especially how you handle hot reload and bundling between native/web targets.
You’ve clearly been deep in the weeds on this, so figured it’d be cool to connect.

[limber wedge]

Just my personal opinion and maybe unjust but I prefer poorly written messages (like mine) compared to ai generated once. I can understand that it can be scary to write in a language you are not fluent in and i feel that too but it just feels a bit rude to me when someone uses ai to talk with me.

But i agree would be maybe a cool blog post for the blog you have been wanting to start (;

[foggy basin]

Wouldn't say I'm deep in the weeds as I just started with this today, but I might write a short blog post about it as soon as I have it all figured out :)

[foggy basin]

Right after I finished my Bevy Birthday post, for the birthday which totally isn't way overdue 🙃

[limber wedge]

Wdym overdue? You are perfectly on time for the 6th birthday

[limber wedge]

rust-analyzer 1.93.0-nightly (d5419f1 2025-10-30) does not like the tokio::select! macro code completions go from instant to 1.5-2s lol

even in a fresh project just adding tokio::select! will result in noticeable perf loss

[pale viper]

Looking at select!'s source code, I'm not surprised. That declarative macro is super recursive and generates a surprising amount of code!

[limber wedge]

yea i was more surprised that this is only an issue with the ra version from this toolchain (not when using nightly-2025-09-18). I guess that its the new trait solver?

[pale viper]

Maybe? I thought the new solver was supposed to be faster, but maybe I'm misremembering

Do we use select! in the CLI?

[limber wedge]

we dont as of now

[rigid bluff]

Hello, for the default 2d project (the one that has github actions for itch.io and other stuff), does it enable all necessary optimizations to run in a production environment or do I have to set it up myself ?

[pale viper]

It should, but check in with the people at #1271949921708146770 to confirm :)

They're the ones who maintain the 2D template

[rigid bluff]

Thanks, also i'm wondering if bevy run web can work for examples ?

[pale viper]

It should! Try bevy run --example my_example_name web

[foggy basin]

I'm late by over a month, but I finally have a draft for a blog post:
https://dev.timjen.net/blog/bevy-fifth-birthday?showDrafts
It's gotten longer than I anticipated, but I'd appreciate feedback if anyone has time to read it :)
Especially if I missed anything important

[shrewd monolith]

Oh, interesting. I'd say something similar to "the bad" has happened to #1236113088793677888. I imagine that'll be common for bigger initiatives, especially those that require upstreaming.

Upstreaming is, well... kinda boring, long, and review-heavy.

So working group members are probably more likely to want to add new fun features.

[foggy basin]

Yea, and then the problem increases in size :D
I'm definitely guilty of this

[foggy basin]

Do you already have a concrete plan for upstreaming, a goal to reach after which you can start the process?

[shrewd monolith]

Yep! We've checked off (nearly) all of the proposed features. So in that sense we're ready to go.

I think our blockers now are API buy-in and maintainer review (and maybe some technical evaluation material).

[foggy basin]

Congrats, very exciting!

[limber wedge]

nice blog! the design is very cute too

[foggy basin]

There's still a lot I want to add, but I kept procrastinating writing the actual blog by fiddling around with the design so I had to stop
I'm not good at design so I used the Catppuccino color palette which does the heavy lifting

[shrewd monolith]

colors are definitely hard for me to pull out of thin air 😅

[foggy basin]

Same for sure. It keeps looking weird when I try to do it myself

And I'm a sucker for pastel colors, so this palette was a great fit for me

[limber wedge]

Oh thanks for the link im so terrible with choosing nice colors so this can help a lot

[limber wedge]

Yea its fine for me if we make a feature freeze now but until there is a clear path to work on for upstreaming i still want to make the cli better

[foggy basin]

Sounds good
(But also now I'm curious how your bevy watch experiment goes)

[limber wedge]

The experiment will continue its more an exploration anyway

Its going great cold reloading for web and native works but there is a lot to clean up hahaa

And like dx improvements with how the build process -> web app and file watcher communicate with eachother

[foggy basin]

In the future we could make it really powerful, that it waits for the bundling to finish, then loads the new JS/Wasm on the JS side in the background and only switches it out once it's fully loaded, so we don't get any disruption from a loading screen

[foggy basin]

Has bevy with default features always been so huge?
Either there is a bug in the CLI or even with our size optimizations the minimal template is 74 MB

I feel like it was less before, but maybe I'm misremembering

[limber wedge]

Yes exactly

[limber wedge]

I think with each version the size with default features increases a bit

[limber wedge]

not fast but it is something

[limber wedge]

code (experiment lol) is here: https://github.com/DaAlbrecht/bevy_cli/tree/bevy-watch @foggy basin if you are intersted. Will just leave it there since i dont think we currently want to add such a big new feature

[pale viper]

That's really cool!!

[pure sierra]

hey guys - i'm trying to use bevy_cli to bundle a wasm build but it's just over 30mb (and cloudflare has a strict 25mb limit) - any ideas to get the wasm file smaller? i tried using wasm-opt but it seems to have corrupted the build:

(index):1 Uncaught (in promise) LinkError: WebAssembly.instantiate(): Import #526 "wbg" "__wbindgen_cast_aa9220ff3b257619": function import requires a callable

[limber wedge]

wasm-opt does the most so maybe try to play around a bit with the different flags / passes? Another thing that could help is setting panic = 'abort'

[twilit dew]

Also disabling debug info

And disabling the debug feature in Bevy

Remove reflection where possible

[rigid bluff]

Hello, I tried replacing the default index.html for my web build, but now when I run bevy run web, it runs in fullscreen rather than in a frame like before.

Is that normal ?

https://thebevyflock.github.io/bevy_cli/cli/web/default-index-html.html

It seems like that's what the html contains, but now I wonder why there is a difference with the default one. I'm also worried it might break the itch.io

[pale viper]

This default index.html page tracks the main branch, not the latest release, and I think we switched to fullscreen recently

Check out https://github.com/TheBevyFlock/bevy_cli/blob/cli-v0.1.0-alpha.2/assets/web/index.html instead!

[foggy basin]

The Bevy CLI should already run wasm-opt for you in release mode, but you can configure the flags to use if needed.
Disabling all Bevy features you are not using probably gives the biggest win if you didn't do that already.
Also note that the CLI allows you to define separate feature flags in dev compared to release, which should help with that

[pale viper]

I think we have a few of these in our issue tracker already, but they're good to note!

[pale viper]

And another thing: I'm sorry for being quite inactive in the past few weeks! School and friends have been eating up a lot of my time, and I've been procrastinating reviewing the PRs that have been building up. I'll probably be inactive for a little bit longer (finals week is coming up!), but I do want to return to the linter and CLI soon

I've been quietly working on a side-project that will hopefully make the Rustup process easier for the linter, but that's not quite ready yet

[fresh scaffold]

commands.spawn(A).insert(B).insert(C) -> commands.spawn((A, B, C))
#135
Something tricky there: For automatic fixes, when some of the inserts are guarded by cfg, that cfg needs to be moved too but the linter doesn't know about it (as far as I understand)

[limber wedge]

No worries its good to take a break from time to time anyway. Good luck with your finals!!

[pale viper]

Good to note, thank you!

[rocky oxide]

We're talking about making web builds require nightly

[foggy basin]

I would suggest to be cautious with that:

• The CLI is not upstreamed yet and of was an explicit goal to make using it optional, making the multi threading required would almost force you to use the CLI
• There will definitely users who can't or don't want to use nightly. On some platforms rustup also won't be available, then we couldn't help with installing the nightly toolchain.
• Game jams work best with web builds, so this could make participation harder (or require testers to download more games)

That said, multi threading definitely gives a lot of benefits for web games, especially avoiding audio stutters is great

[shrewd monolith]

Well, part of the conversation was that upstreaming the CLI is very compelling for this. I think both efforts could take a similar amount of time, so we can't rush into it, to be clear.

In any case, I don't mind a world where people are heavily encouraged to use the CLI. After all, even with guides for how to tune your manifest for fast compilation, how many new users actually do it? How many people continue to have unnecessarily long compile times? I'm just guessing, of course, but I bet it's more than you'd think.

I'm also curious on how impactful platforms without rustup would be. Does this maybe comprise just nix for now? And do you think it would make game jam web builds harder assuming an upstreamed CLI? We've only done jams on itch.io as far as I know, and the only thing you have to do is check a box for the headers. (Certainly more than nothing, but hopefully not enough friction to be prohibitive.)

(I guess the "compilation performance" is only true if you seek out a template, but... the rest of my point should stand. Also, building for the web is already almost prohibitive for newcomers!)

[foggy basin]

And do you think it would make game jam web builds harder assuming an upstreamed CLI?
Assuming that Bevy CLI is used, I think it's not really harder, I meant more for people who don't use it

To be clear, I'm not really personally opposed to the idea, I just anticipate that it might receive some pushback and should be handled carefully :)
Multithreading definitely has a lot to offer

[twilit dew]

Exactly my thoughts

[snow linden]

can anyone in this group who worked on the nightly web support for the cli help me verify the correctness of this section: https://hackmd.io/huo8WtmjRs-hanU-5Oa5Uw?both#44-Web-Multithreading-Requirements-Benifits-amp-Costs

one interesting thing i dug up while looking into this, the same source headers that unlock shared memory also unlock goodies like high-precision timers.

[snow linden]

caution is warranted. but my argument in favor is basically:

• web is the first point of contact for most people, through examples and game jams
• we can't hit our baseline performance / quality targets on the web without these features. timers don't work, operations are slow, things crash, audio stutters
• supporting these sub-par non-threaded non-nightly non-cors-header web builds costs a surprising amount (both in developer resources and in engine complexity) considering how little it benefits us

[shrewd monolith]

+bulk-memory and +mutable-globals are now defaults for wasm32-unknown-unknown. https://doc.rust-lang.org/beta/rustc/platform-support/wasm32-unknown-unknown.html#enabled-webassembly-features

[snow linden]

right, ty

part of what's been historically annoying about this is that it has been technically unstable. the guidance has shifted a lot over time

now it's seems mostly to have stabelized, but i imagine guidence will change again in the future.

[shrewd monolith]

To be fair, those flags would work just fine. They're just no longer necessary. I don't think anything truly breaking has occurred here for a long time, but I've only been on it for a couple years.

[limber wedge]

While requiring nightly would add more burden i personally think that its already at a point where its kinda unusable without the CLI (or some sort of GH action).

So I think an upstreamed CLI would help a lot. Its so annoying / complex to create good web builds that i would argue that most who do not use the CLI, dont know how to create a good web builds and just haven’t heard of the CLI.

[foggy basin]

itch.io claims to enable these headers automatically.

Is this new? My last information was that you need to manually enable that in the settings (but I haven't checked in a while)

I wonder if people who use Bevy on production already use nightly.
I believe @dusky onyx and @silent shard used bevy on the web?

[foggy basin]

Regardless, this means we should improve our nightly support in the CLI.

• Automatically running with a nightly toolchain for multi threaded builds, if not already activated
• Automatic installation of nightly if rustup is available and nightly is missing
• Better error messages in these cases

Oh and I think this also makes it worth it to add the +toolchain syntax after all, what do you think @pale viper?

[dusky onyx]

I don't currently use nightly for work, but I would be happy to do so if it enables use of web workers.

[foggy basin]

May I ask which tooling you use to build bevy for the web?

[dusky onyx]

Currently we're invoking wasm-bindgen and wasm-opt manually, originally we used wasm-pack but it had a lot of bugs. I'll probably try to use the bevy cli at some point

[silent shard]

Not using nightly, using trunk to invoke the other tooling 🧐

[limber wedge]

Would be valuable feedback we do exactly that

[pale viper]

Yup, if we’re committing to making nightly more integral to Bevy, +nightly would be very nice

At least, it’s better than recommending everyone do rustup run nightly bevy …

[limber wedge]

How does supporting the +toolchain syntax help here? I personally dont think that this is an acceptable solution

Rather that the cli uses the +toolchain syntax internally but i dont think it has to be visible to the user (unless —verbose was passed)

[molten merlin]

is the cli going to mandate a nightly toolchain version then? or how would a user specify a specific nightly?

[pale viper]

If we're going to make nightly mandatory for web builds, it would be nice to allow the user to configure which nightly is chosen. I could see something like this in the future if we go down this path:

# Uses stable by default
$ bevy build

# Uses nightly by default
$ bevy build web

# Override to use a specifically nightly
$ rustup run nightly-2025-11-27 bevy build web

# This is nicer to write
$ bevy +nightly-2025-11-27 build web

I originally discarded the +toolchain syntax for the CLI because I thought it added too much complexity, plus it made it harder to support non-Rustup systems

Making nightly mandatory for web does sway me a little, though. What do you think?

I feel like we need to figure out the story for how the CLI handles toolchains. How much user input should be needed to setup the toolchain?

[limber wedge]

A yea that make sense. I still would like to add a way so you dont have to specify each time if you dont want too. Maybe a config option or so

[foggy basin]

I'm imagining that the Bevy CLI would automatically enable nightly when it's required (ie on multi threaded web builds), but I think the +toolchain syntax is still nice to have, e.g. to pin the nightly version to a previous one if the current one has a bug

The automatic usage of the nightly toolchain would be more useful for one off cases like running an example in the web, I think for web projects the user would instead use a tollchain file or rustup override set nightly

[twilit dew]

that looks like very neat syntax / semantics 🙂

[rocky oxide]

Similar flavor to the work y'all do here

[rigid bluff]

Hello, the itch.io github action was working fine until recently it stopped working with this error:

info: bundling JavaScript bindings...
info: optimizing with wasm-opt...
[parse exception: duplicate export name (at 0:187062)]
Fatal: error parsing wasm (try --debug for more info)
warning: failed to run wasm-opt, trying to find automatic fix...
error: command `wasm-opt --output /home/runner/work/bevy_kart/bevy_kart/target/wasm32-unknown-unknown/web-release/bevy_kart_bg.wasm /home/runner/work/bevy_kart/bevy_kart/target/wasm32-unknown-unknown/web-release/bevy_kart_bg.wasm --strip-debug -Os` exited with status code exit status: 1

Anyone familiar with it ?

[limber wedge]

hmm what error do you get when you run wasm-opt --output /home/runner/work/bevy_kart/bevy_kart/target/wasm32-unknown-unknown/web-release/bevy_kart_bg.wasm /home/runner/work/bevy_kart/bevy_kart/target/wasm32-unknown-unknown/web-release/bevy_kart_bg.wasm --strip-debug -Os ?

[rigid bluff]

I'm gonna try to run that command on windows somehow, just realized in my question I forgot to mention it was a github action

the game runs fine locally

[limber wedge]

so running bevy build --locked web --bundle works fine locally but not in the github runner?

[rigid bluff]

just tested it and yes

Used to work just fine, maybe it's a version problem with it using latest and a newer coming out that breaks it or something

[rigid bluff]

https://discord.com/channels/691052431525675048/1019697973933899910 I made a help post about it to not pollute here

[tardy cove]

does the bevy cli have commands for android yet?

[crude mica]

nope

i want to help contribute this at some point but i'm being pulled in multiple directions, if circumstances align it is likely i'll be able to contribute this in ~7 months

[tardy cove]

oof

[foggy basin]

@hollow geyser what is your concern about the editor depending on the CLI?
The current CLI prototype has a public library that you can use instead of creating a CLI process directly, is that what you mean by common API?

[limber wedge]

I think the wording in the document is just a bit unfortunate.

[hollow geyser]

Ah, thanks for clarifying. But I think "CLI" is a confusing name for a library. People usually associate CLI with a user-facing frontend, so the idea of one frontend (the editor) using another frontend (the CLI) didn't make sense to me.

[twilit dew]

any idea what this means?

from bevy run web

[pale viper]

Looks like this line in wasm-bindgen is causing the error: https://github.com/wasm-bindgen/wasm-bindgen/blob/e58b99aea29a3a717f50257eaf161ab13c4aae48/crates/cli-support/src/interpreter/mod.rs#L234

I guess wasm-bindgen has a tiny WASM interpreter built-in? I'm not quite sure...

[twilit dew]

cool santa hat 😄

[pale viper]

Thanks! I was feeling festive :)

[twilit dew]

I'll try without web-multi-threading in case that changes something

indeed!

works without the web-multi setting

[pale viper]

Huh. Looking at the code surrounding breaks_if_inlined(), the panic was caused by casting one type to another

I don't fully understand what is happening in there, but I'd definitely open a bug report to wasm-bindgen!

[twilit dew]

do you think they'll accept it if the repro is "plz run bevy run web"?

[pale viper]

Hah, probably not! I'd check and see if the command spit out by bevy run web --verbose also causes the panic, and try to minimize it from there

[twilit dew]

that would be good, but I don't have much time atm

oh I didn't use the newest nightly

maybe it's already fixed there?

[pale viper]

Be careful with the newest nightly, actually! wasm-bindgen may be broken because they changed the symbol mangling scheme

If you bump nightlies, make sure you're using wasm-bindgen v0.2.106

[twilit dew]

lol thx

[pale viper]

Yup, gl :)

[twilit dew]

different error!

good thing that the page I'm deploying doesn't use audio

[twilit dew]

deployed! https://janhohenheim.itch.io/surf

(just without multi-threading for now )

[limber wedge]

not sure if this helps but im pretty sure that wasm-bindgen-cli v0.2.106 works with v1.92.0-nightly / v1.93.0-nightly (the nightly versions we use for the linter)

[foggy basin]

It's both :)
You can use it as a standalone application in your terminal, or call the same functionality as a lib in rust.
Although it should be noted, that most of the functionality still results in executing CLI commands, like cargo and wasm-bindgen

[pale viper]

@limber wedge @foggy basin I've made the final touches on the CLI and linter upstreaming document. Could you take a peak at https://hackmd.io/@bevy/H15ftGooxx, and let me know if you approve? Once so, I plan on pinging the maintainers and trying to get an official consensus

There's a few decisions they need to make, namely:

• Does the code go in bevyengine/bevy_cli or bevyengine/bevy?
• Should the code be reviewed, adjusted, and transferred in separate steps? Or should the code be broken up into small segments that get reviewed and transferred individually?
• Should past versions be released on crates.io for historical purposes?
• What should the Discord channel be named? Are we the CLI devs, or the tooling devs?
• Are they cool with appointing us as SMEs? What should the titles be?

And since it's been a hot minute, I hope you all are doing well! It's pretty cold outside where I am, but the snow on the ground and the festive cheer makes up for it :)

[limber wedge]

Thanks so much for creating this! I have been peeking at it from time to time ^^ and you already addressed all my feedback so for me this matches!

[limber wedge]

Same (just without the snow part) i am really enjoying December with all the activities (and advent of code)

[pale viper]

Oh, I want to try AoC at some point! Sounds fun :)

[pale viper]

<@&1064695155975803020> it's been a year and 4 months since the CLI working group was created, and I think we finally have a solid plan for upstreaming the prototypes! Please take a look at https://hackmd.io/@bevy/H15ftGooxx and let us know your thoughts, opinions, and concerns

I'd like a few days of discussion, then ideally we can get the ball rolling by next weekend. By then I'll be in winter break and will be able to devote more time to actually doing the upstream

[analog fern]

Looking now!

[plush spade]

so in fish shell for cargo i get auto-complete for example names which is SUPER helpful, it would be nice to have this work with bevy too. not sure about other shells here

[limber wedge]

bevy completion iirc

[plush spade]

ooo!

[limber wedge]

you can add this to your bash / zsh / fish profile

[plush spade]

it would be nice if it just installed? is there a limitation to that? typically i expect tools to install completions for me

[vast vine]

I never really bothered setting up completion in the past but bevy has so many examples now that you made me want to try setting it up 😅

[plush spade]

it's really helpful imo i can never remember all the example names

[pale viper]

That's not something I think we can easily do with cargo install-d programs, although if we added the CLI to package managers like Brew or APT we totally could!

[limber wedge]

oh you ment for examples

not sure if that works i thought it does

[vast vine]

I mostly just touch the ones I wrote so I used to be fine, but at this point I just wrote too many and still working on a few more

[plush spade]

i might have missed it but does cargo install have any post-install text it displays we could direct users to?

[pale viper]

I don't believe so, unless we wanted to try printing something through build.rs (although that's kinda hacky and may not work)

[twilit dew]

What’s the feeling on allowing custom bevy subcommands? i.e. like how the executable cargo-foo can be invoked as cargo foo. Can we have bevy-bar be run as bevy bar?
The reason is that I'm toying with the idea of creating a connectivity layer between Source 2's Hammer level editor and Bevy, and that would require a CLI. Since that CLI does not have any meaning outside a bevy context, it would be neat to have it be run as bevy hammer or something like that

[limber wedge]

I think it could be a neat idea to be able to run custom subcommands, just like there are so many third party crates that do a lot of heavy lifting that bevy cant do itself or bevy does not want to do i imagine it will be the same for the cli

[twilit dew]

I have not looked into this at all, but I imagine it would be trivial to implement, right?

Since you basically just invoke another CLI and forward the params

[limber wedge]

i think the tricky part is more how to integrate it in clap. iirc cargo also lists the installed external clis so they are "real" subcommands

[pale viper]

Yeah, I think it would be great if the CLI supported subcommands like that

[pale viper]

I think we might need to dip into clap's builder API to support this, but I've never really looked into it :)

[analog fern]

Off the top of my head, the concerns that come up are:

1. Namespacing: theres always the risk for custom command authors that we will "claim" a given command name. The onus would be on 3rd parties to pick a name that we are unlikely to claim for ourselves upstream.
2. Consistency / quality control: We'd be allowing arbitrary 3rd parties to look and feel "official" in a way that could negatively affect our reputation (ex: malicious, UX that is inconsistent with upstream bevy_cli UX, bad / buggy UX, etc)

If we introduce some sort of "would you like to install" dialogue for custom commands that aren't installed yet, (2) becomes even more of a concern, as we'd be opening our users up to typo-hijacking (or "useful looking") malicious crates. (ex: a developer enters bevy publish, and we print "bevy publish is not a command, consider installing bevy_cli_publish, which provides the bevy publish command")

Given that people can already easily run cargo install bevy_hammer, is it really that bad to type bevy_hammer instead of bevy hammer, given that it trivially solves (1) and (2) ?

[twilit dew]

Seems to me like both of these are true for cargo subcommands, yet those don’t run into these problems in practice, no?

[analog fern]

Hard for me to say as I don't really use them myself, nor am I in the loop for security issues that turn up

I personally find the cost:benefit of the feature in cargo dubious

The balance of the "neatness" of the feature with the issues of provenance / trustability / consistency doesn't really play out from my perspective

Not exactly the same, but its similar to letting people nest themselves under the bevy crate as subcrates. Which I would never support, for the same reasons

Or letting people host arbitrary pages at bevy.org/X

I think it makes more sense if we were acting as some sort of "plugin host" and defining a set of protocols that they implement. But we'd literally just be proxying bevy X to bevy_X

Also: I'm midway through a review of the bevy_cli code and the upstreaming proposal. Not leaving comments yet as my opinions on some of these issues require a better understanding of the actual state of the code. At this point I'll just say that I'm on board to start the upstreaming process soon in one way or the other, but I'll need a bit more time to grok things.

I'm temporarily tabling my review to focus on prepping 0.18. I think its too late in the game to try landing this in 0.18.

[pale viper]

Gotcha! Sounds good

Side note: I reserved the bevy_linter crate to protect against typo-squatting / people accidentally installing that rather than bevy_lint. I'm happy to transfer ownership once the upstream is done

[limber wedge]

I think jan ment more that if you had installed a tool (with cargo install) that is named bevy_* that it can be then run via the bevy_cli but we would not install any of those. So imo there is no concerns with that since its the user that is responsible and installing the tools via cargo install.

[twilit dew]

Yep exactly

[analog fern]

That flavor of design is certainly in some ways less risky than having the bevy cli facilitate the install (for the reasons stated). Although on the flip side it opens up new problems:

1. Any bevy_x in the path (even one that wasn't built to be a bevy subcommand) is now available as a subcommand.
2. We no longer have the ability to block the installation of known bad actors in the space.

That being said, even ignoring those issues, the consistency / quality control / provenance problem is enough on its own to deter me from this path. The sole functionality of this feature is "let arbitrary 3rd party tools present themselves as first party tools". There isn't any functional difference between bevy X and bevy_X. It is "just" branding.

[pale viper]

Rust 1.92.0 is out, meaning it's time for another Rustup for the Bevy Linter! https://github.com/TheBevyFlock/bevy_cli/pull/697

I'm really surprised by how easy the upgrade this time was! I ran cargo build and it passed the first time :D

[limber wedge]

No breaking changes!!! Imagine

[pale viper]

I know lol

My worst fear is that one of these upgrades has a silent logic breaking change that isn't caught in our tests

Hopefully our UI tests exercise the lints enough that we would catch something like that 😅

[limber wedge]

Yea thats true but i think that would only hit in edge cases since the ui test are pretty good imo

[neon idol]

Hey, any love for HTTPS planned?

https://github.com/TheBevyFlock/bevy_cli/issues/709 is my specific need

[rigid bluff]

Hello, I can't seem to figure out what would be the bevy run equivalent of cargo run --example tic_tac_toe -- server

[limber wedge]

Hey i think this would be nice to have but we are a bit in a limbo since we are waiting for maintainers to review our upstream proposal and what comes out of it so i think it will take some time until we support this

[foggy basin]

Should be bevy run --example tic_tac_toe -- server if I'm not mistaken

[rigid bluff]

it's what I tried but it gets me:

bevy run --example tic_tac_toe --
 server
error: unrecognized subcommand 'server'

Usage: bevy.exe run [OPTIONS] [COMMAND]

For more information, try '--help'.

[rigid bluff]

Can anyone help I still can't figure it out

[limber wedge]

so if server is the argument you want to pass to the bevy app the command is like this bevy run --example tic_tac_toe -- --server

[rigid bluff]

bevy run --example tic_tac_toe --  -- server
error: unrecognized subcommand '--'

Usage: bevy.exe run [OPTIONS] [COMMAND]

For more information, try '--help'.

It doesn't seem to work either

[limber wedge]

you need to remove the extra space between -- and server

bevy run --example tic_tac_toe -- --server

[rigid bluff]

I thought you had made a typo, I tried it too and same outcome

bevy run --example tic_tac_toe -- --server
error: unrecognized subcommand '--server'

Usage: bevy.exe run [OPTIONS] [COMMAND]

For more information, try '--help'.

[limber wedge]

what version are you using?

[rigid bluff]

I was on bevy 0.1.0-dev, upgrading it fixed the issue thanks a lot

[limber wedge]

glad to hear! 🎉

[rigid bluff]

bevy run --example tic_tac_toe -- server

Works like I expect, but now i'm trying to run it on web but whever I add the web arg it gives me an error (ex: bevy run --example tic_tac_toe web -- server, do you know what is the correct way ?

[tepid depot]

I'm afk but I'm pretty sure web has to be last

[limber wedge]

i dont think that this works at the moment

the problem is that claps last is not compatible with subcommands iirc

[foggy basin]

Can you create a ticket for this? That needs to work :)

[limber wedge]

yes will create one https://github.com/TheBevyFlock/bevy_cli/issues/711

[rigid bluff]

Thanks all, I would really appreciate a fix for this, I wonder if there is a workaround in the meantime

[limber wedge]

correct me if im wrong @foggy basin but i dont think that there is a workaround since you cant just pass run time arguments to a wasm binary but we would rather need to make a custom main function and piping the command line arguments over our dev server to the wasm binary or something like this?

[foggy basin]

That seems right to me

[rigid bluff]

Hello, is there anything I can do to help with the web args issue ? A solution would really help me

Even though I do not know much about CLI I could try,
Is there an easy way to test changes locally for the CLI ?

[limber wedge]

Hey in my estimation support wasm cli args is a rather complex feature but a PR is always welcome! Depending on how complex the changes are I can’t promise that we would merge right away since i would like to keep the code base pretty stable until cart had the time to review the upstream proposal.

You can easily test the cli by just building your local change with cargo build —path .

But i think depending on your usecase maybe just „hard coding“ the behavior behind a feature flag is the easier workaround. It wont be runtime configurable but at least you could easily test by rebuilding

[rigid bluff]

the problem is that I need to run two instances with different setups often (one client one server), so i'm not sure if there is an easy way to achieve that

[foggy basin]

It would be rather ugly, but could you make it work with feature flags?

Ah, the rebuild would be annoying. Right

[rigid bluff]

I'll work on other stuff in the mean time it's fine

[foggy basin]

Do wasm binaries support being called with arguments in general?

[trail shale]

no, because you don't call the wasm binary

[foggy basin]

Right, we just work with the JS bindings

[trail shale]

it exposes a few functions, and you call those. to pass arguments, you would have to expose a new function that takes those parameters, and change the html to call it with the correct args

[foggy basin]

Then we probably can't provide that functionality in a way that works out of the box

Does it make sense to run the server in the browser anyway? Is it a special form of the client?

[foggy basin]

Another workaround could be 2 different binaries using the same library for the core implementation and calling it with different arguments. But I know it's also not ideal

[rigid bluff]

it is a special kind of client yes, it's my magic serverless browser multiplayer magic.

Now that I think about it a reasonable solution is that whether the user is a host or not is decided at runtime, which I will have to do anyways

though i'm kinda sad args are not possible because it made quick tests simple, I have a hard time believing there is no way to make it work

[limber wedge]

I have my last exam this Saturday i could prepare a 0.5.0 release afterwards? I think this would make sense even tho maybe the only change is being compatible with 0.17 what do you think? @pale viper

Im still really motivated to work on both so cant wait until cart got some time. In the meantime i actually started creating a game for once

[pale viper]

Yup, sounds like a good plan! Would you like to do the actual release process, since you've never done it before?

[limber wedge]

Whatever you like. I dont think that the release process is particularly interesting so i dont want you to always have to do it😂

[pale viper]

Yeah, you should totally give it a shot! It's good practice, plus I'll be a bit busy in the coming week

Good luck on your exam :)

[limber wedge]

Sounds good. I will prepare it once i have time and then just add you as a review so you get notified

[limber wedge]

Thank youu!

[ancient dirge]

Heyo! I was told this might be nice for upstreaming into this potentially? https://crates.io/crates/bevy-patch

It mostly just does a scrape of the github api for the crates/* folders, which seems to work well (or just reads the directories in bevy/crates/* on local paths

also doesn't modify your Cargo.toml, just prints out the patch list

was thinking of improving the usability a little bit like adding a way to give it a link to a PR on bevy/some other remote and have it automatically figure out the repo/branch for you, or allowing for things like:

bevy-patch git --repo aceeri/bevy # expands to https://github.com/aceeri/bevy

also stuff like:
--tag v0.18 -> v0.18.0
or gives you suggestions on that

[shrewd monolith]

oh that would be so nice right inside the bevy cli

[molten merlin]

don't forget to mention it on the issue too: https://github.com/TheBevyFlock/bevy_cli/issues/79

[pale viper]

Really cool! The implementation looks very nice, I definitely think that's a good candidate for being merged into the CLI :)

[snow linden]

Hello all! We have a project proposal for gsoc that involves the CLI, but it only has one mentor. Do we have anyone else who would be willing to help spend some of their time mentoring a student on cli work over the summer?

[limber wedge]

ohh thats soo cool! I would have time to help out

[snow linden]

there's details in the #1460367944193282089. if you or anyone else is interested, see row 14 here https://docs.google.com/spreadsheets/d/1ehuIyy32z1CDBpdSaYLEUCT3J3EOiV7v5eRcNVGMEVQ/edit?gid=0#gid=0

[limber wedge]

i think mentoring would be really fun im just not sure about

The exported package output by wasm-bindgen should offer true memory isolation when mounted to a canvas
Without that the task would be pretty simple and a nice way to get started with the CLI but with it it seems like its maybe more a task for wasm-bindgen than bevy?

i can still just add myself as a mentor and we will see if anyone in the end is interested in that. imo contributing some lints would also be really interesting

[snow linden]

@neon idol this is a good point, are you sure this is something a student can hadle?

(sorry if i am pinging the wrong person)

[snow linden]

@limber wedge I talked to them out-of-band, they have a workaround for if we can't get a fix into wasm-bindgen. basically just patch the thing after it's been built, should be something a student could do with guidence.

the other dev knows how to do that bit and has a working prototype, so i think someone who knows the cli would be great as a second mentor.

[limber wedge]

okay thanks a lot for getting this sorted! will add my details

[snow linden]

fantastic!

[trail shale]

@snow linden I'm pretty sure the "multiple simulatenous canvas" part is blocked by winit with will panic if more than one instance is started

at least it was last time I tried something similar and I haven't seen a fix for it passing through

[snow linden]

spencer apparently has a prototype at his work that supports this, and he's willing to share it for this

[trail shale]

oh nice!

[limber wedge]

https://github.com/TheBevyFlock/bevy_cli/pull/724 @pale viper If you have time could you take a first review? 🩵

[pale viper]

Absolutely! I’ll be traveling Friday, so I’ll make sure to review it on the bus then if not earlier :)

[foggy basin]

https://discord.com/channels/691052431525675048/1463631263222202627
A lot of stuff here us relevant to us

[jovial quartz]

Are there any templates making use of the new feature groups stuff

I did not see any updates to use the groups on the git or the template git

[buoyant jasper]

Hi, I was wondering if the linter has some warning for SubStates that you are initializing with init_state... I just had issues with this "footgun". 😅

If not already present (I don't think there's a lint for this) should I open an issue in the cli repo?

[foggy basin]

Not that I'm aware of, but maybe you can suggest it over at #1271949921708146770 :)

[foggy basin]

I'm not familiar, can you expand a bit further on the details of this footgun?

[buoyant jasper]

Yeah! I was, for example, using said substate with DespawnOnExit for some entities. And the assumption is that a substate will not be present if its source state is also not the current state. Using init_state breaks this assumption apparently.

[foggy basin]

For the lint, what would be the situation to detect and what the proposed fix we should suggest?

[buoyant jasper]

Let's say the user has a MyState struct which derives SubStates and they are initializing it with init_state, just issue a warning and add "maybe you wanted to use add_sub_state?" If that makes sense.

[rigid bluff]

Hello, just something that crossed my mind, but couldn't we get editor/compile time validation of asset types with (or maybe without) the CLI, something like checking if a gltf has a certain animation or similar

[pale viper]

Maybe! I definitely would like to improve integration between asset processing and the CLI

[shrewd monolith]

Looks like there are some new requirements for multi-threaded Rust Wasm.

Hopefully it's not too much of a burden to get these changes in even as the upstreaming evaluation progresses

I should be able to get to a PR in a few days if no one beats me to it. I believe the change would be pretty trivial.

[snow linden]

i think this is the right call by rustc

although it's annoying

[foggy basin]

Yes, I'd happily accept that PR :)
Luckily we should be able to do it with no user-facing effects

[limber wedge]

<@&1064695155975803020> Helloooo! bevy_lint is ready to release v.0.5.0 (a bit late) so we can have a released version that is compatible with bevy 0.17 before we support bevy 0.18! As per our release process we need a maintainers approval on https://github.com/TheBevyFlock/bevy_cli/pull/724 before we can release. I would appreciate if you could take some time and leave your feedback

[rocky oxide]

I'll do this today

[limber wedge]

thank you!

[pale viper]

Yeah, we could probably put out a patch release for this too

[rocky oxide]

🚀

@pale viper merging the PR; please ship at your leisure (but also please have a version that works with 0.18 out for the jam 🙏)

[limber wedge]

I have a branch already ready so main should be compatible in time for the jam

[pale viper]

Thank you! I’ll get that out now :)

[pale viper]

Done!

[limber wedge]

thank you!

[twilit dew]

hey friends! Getting this in CI

[rocky oxide]

Did you update Rust?

[twilit dew]

I'm veeeery out of the loop here, but I think that feature is now stabilized and bevy-lint is not yet on that version?

[rocky oxide]

Yes

[twilit dew]

I updated it to what the CLI uses: https://github.com/TheBevyFlock/bevy_cli/blob/main/rust-toolchain.toml

nightly-2025-12-11

[rocky oxide]

Hmmm

[molten merlin]

did you bump to 0.18? I don't think the linter supports that version yet

[twilit dew]

indeed I did, but that shouldn't result in that error methinks

[molten merlin]

I would test it on a 0.17 project to see if it does the same though, to confirm

[foggy basin]

There is an open PR to update the nightly version, maybe that will fix it: https://github.com/TheBevyFlock/bevy_cli/pull/729

[dark oasis]

why is the argument order so weird and counterintuitive on bevy_cli

oh, i think i get it now

-- options are for the arg immediately before it

[pale viper]

Is it with the bevy build web stuff?

[dark oasis]

so ⁨bevy run --example 3d_scene web⁩ is just weird looking

needing to put ⁨--features wasm⁩ also before web is kinda weird

or not wasm

webgpu

[pale viper]

Yup, I agree! It’s a paper cut in the argument parser

[twilit dew]

FYI it looks like bevy_lint on ⁨main⁩ is working well for me 🙂

[foggy basin]

Basically the cargo options are on build/run, the web-specific options are on web.
I think it makes sense, also keeping in mind the --help output.
But many people have said it's counter intuitive so maybe we need to change it.
So what would be the expected behavior?

[quaint cipher]

I would guess that most people are used to -- flags being independent of position in the command; ime it’s fairly rare for there to be a restriction on where you can put those flags beyond maybe “after this argument everything gets gathered and used as a shell command, so put your flags before it”

[limber wedge]

Yea i think thats the most common way

[foggy basin]

I think what would be important is that we still emit errors when flags are used in a place where they don't make sense. E.g. when you set the port when running a native instead of a web app.
I'll have to take a look which parsing options clap offers

[pale viper]

Try it again in 5 minutes! I just hit merge on https://github.com/TheBevyFlock/bevy_cli/pull/703, so the linter should now officially support 0.18

Speaking of which, I think we should probably prepare another linter release so that game jammers can use it (Bevy Jam starts in 6 days!)

Let me get that kicked off

[pale viper]

<@&1064695155975803020> Hi again, I feel like we keep on doing this! 😄
We are ready to release v0.6.0 of ⁨bevy_lint⁩, with the only change being Bevy 0.18 support in preparation for the upcoming jam! When you have the time, please take a look at https://github.com/TheBevyFlock/bevy_cli/pull/731 and give us a review so we can make another release. Thanks! :)

[rocky oxide]

Approved 🙂 Boy I can't wait until this does not rely on nightly lol

[pale viper]

Thank you! Being on stable would be really nice, but I doubt that will ever be possible unless project-stable-mir with their ⁨rustc_public⁩ crate stabilizes

Huh, I guess we could technically use ⁨RUST_BOOTSTRAP=1⁩. This would let us use nightly features on stable Rust

[rocky oxide]

😨

[pale viper]

Yeah...

The Rust project definitely does not like people using ⁨RUST_BOOTSTRAP⁩, but it is an option...

[pale viper]

I'm getting deja-vu, I feel like I just did this! :)

[snow linden]

what

👀 👀 👀 what are the downsides

[pale viper]

The largest downside is that we will have to release the linter more often. That is, a new linter release for every stable Rust release (every 6 weeks, I believe)

[rocky oxide]

Extremely cursed and explicitly unsupported

[pale viper]

That, and also we'd be technically misusing ⁨RUSTC_BOOTSTRAP⁩ and will get zero support (as Alice said)

[snow linden]

new bevy tagline just dropped?

neat, didn’t know that existed. sounds like something we can’t do (but am going to go to a crossroads at midnight and try it out anyway)

[pale viper]

Lol yeah. For extra fun, set ⁨RUSTC_BOOTSTRAP=-1⁩ to convert a nightly compiler into a stable-only compiler (no ⁨#![feature(...)]⁩ support!)

Even if the Bevy Linter never gets upstreamed, I'm so glad I made it for all the random cursed Rust compiler knowledge it gave me

[twilit dew]

Friendos, how would y'all feel about the default page for web deployments shipping a little JS snippet that displays a text when the Bevy canvas crashes? The reason this came up is that currently, running WebGPU jam entries on unsupported browsers looks like the loading screen got stuck

So in that case, having a message like "you need WebGPU, enable it with blablabla" would be neat

And since that requires looking for exceptions, we could just as well display a message in the general case as well

CC @shrewd monolith @grave quarry

[limber wedge]

I like the idea!

[shrewd monolith]

Yeah I think it should be relatively easy

[foggy basin]

i think we already have an issue for better error handling somewhere :)
Definitely would be nice to have!

[limber wedge]

I think changing this makes a lot of sense. I was first also a bit confused with the ordering. And i dont think we will have overlapping arguments from web / native that requires this separation

[foggy basin]

I think it would be confusing if you did ⁨bevy run --help⁩ and it also shows web specific flags.
But if we can avoid that, I'm totally down!

[limber wedge]

Yes totally!

[pale viper]

@limber wedge and @foggy basin, definitely take a look at this! We might end up upstreaming the CLI before the linter

[limber wedge]

Glad to hear this! Im surprised by that.while the linter has its own pain points (that could be improved via upstreaming) it itself seems more like the big picture is solved since we are basically just our own clippy.

But the cli is definitely more useful as of now

[pale viper]

I finally sat down today to learn Nix, and I now think I understand it enough to review changes on the flake.nix PR (https://nix.dev was super nice!)

I needed to make a few changes in order to get it merged, and I wanted to add Github Actions checks while I was at it, so https://github.com/TheBevyFlock/bevy_cli/pull/733 is now up for review. Please test it if you get the chance!

@craggy valley thank you for your effort and patience!

[limber wedge]

so did you switch to nix?

[pale viper]

No, but I am tempted now! I ended up doing my testing in a virtual machine

[limber wedge]

hahah they got you

[tardy cove]

i've been using nix for some time now but have not touched flakes yet

[pale viper]

@limber wedge @foggy basin we should probably make a release of the CLI before the jam in 2 days. Is there any PR that you want merged before I start that process?

[limber wedge]

i think https://github.com/TheBevyFlock/bevy_cli/pull/629 could be nice but open to you!

[twilit dew]

Does the new release include the new required options for Wasm multithreading?

[limber wedge]

Yes

[twilit dew]

hmm is there an issue with the nightly used for the newest CLI?

[trail shale]

I don't know how to look further back than https://rust-lang.github.io/rustup-components-history/ but it's rare nowadays that something's missing

[foggy basin]

I'm always happy to read that people have a positive experience using the CLI!

[twilit dew]

the CLI hard-powering our jam submission hehe

[pale viper]

Have you noticed anyone running into https://github.com/TheBevyFlock/bevy_cli/issues/642 in #jam? That's the bug where we now need to specify certain linker flags in WASM with --unstable multi-threading

[limber wedge]

I am pretty sure jan is always installing from main

[pale viper]

I was planning on shipping a release last Friday to get the fix out to everyone, but ended up having to dedicate that time to homework 😅

[pale viper]

Yeah, and I'd probably recommend that to anyone who hits that bug

[shrewd monolith]

Several people have, yes.

[twilit dew]

bingo

[silk delta]

As a heads up, getrandom v0.4 is out now, but for Web WASM support, it does what getrandom v0.3.4 does, so there's nothing new on that front. The heads up is because bevy_rand now supports rand/rand_core v0.10 and by extension getrandom v0.4, so this likely should be accounted for by the CLI

I've done a PR to glam to begin the process of advancing rand support, and other crates like uuid are going to update getrandom too

As a plus, I think ring will update to getrandom v0.3 soon (MSRV woes means it can't update to v0.4) so the last getrandom v0.2 dep will likely finally migrate

[pale viper]

Good to know, thanks for the heads up!

[molten merlin]

I've run into a situation where bevy_cli behaves differently based on whether you're compiling in dev vs release. Specifically, getrandom becomes an issue, but only if you're compiling bevy build --release web instead of bevy build web.

I don't really have that much time to figure out what is going on, but wanted to mention it. Not sure what approach I'm going to take to fix my build yet

[pale viper]

Could you send the error message that you’re getting, with —verbose?

[molten merlin]

error: The "wasm_js" backend requires the `wasm_js` feature for `getrandom`. For more information see: https://docs.rs/getrandom/0.3.4/#webassembly-support
  --> /Users/chris/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/getrandom-0.3.4/src/backends.rs:40:17
   |
40 | /                 compile_error!(concat!(
41 | |                     "The \"wasm_js\" backend requires the `wasm_js` feature \
42 | |                     for `getrandom`. For more information see: \
43 | |                     https://docs.rs/getrandom/", env!("CARGO_PKG_VERSION"), "/#webassembly-support"
44 | |                 ));
   | |__________________^

error[E0425]: cannot find function `fill_inner` in module `backends`
  --> /Users/chris/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/getrandom-0.3.4/src/lib.rs:99:19
   |
99 |         backends::fill_inner(dest)?;
   |                   ^^^^^^^^^^ not found in `backends`

error[E0425]: cannot find function `inner_u32` in module `backends`
   --> /Users/chris/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/getrandom-0.3.4/src/lib.rs:123:15
    |
123 |     backends::inner_u32()
    |               ^^^^^^^^^ not found in `backends`
    |
help: consider importing this function
    |
 33 + use crate::util::inner_u32;
    |
help: if you import `inner_u32`, refer to it directly
    |
123 -     backends::inner_u32()
123 +     inner_u32()
    |

error[E0425]: cannot find function `inner_u64` in module `backends`
   --> /Users/chris/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/getrandom-0.3.4/src/lib.rs:137:15
    |
137 |     backends::inner_u64()
    |               ^^^^^^^^^ not found in `backends`
    |
help: consider importing this function
    |
 33 + use crate::util::inner_u64;
    |
help: if you import `inner_u64`, refer to it directly
    |
137 -     backends::inner_u64()
137 +     inner_u64()
    |

For more information about this error, try `rustc --explain E0425`.
error: could not compile `getrandom` (lib) due to 4 previous errors
warning: build failed, waiting for other jobs to finish...
warning: failed to run cargo, trying to find automatic fix...
error: command `cargo build --config profile.web.inherits="dev" --no-default-features --profile web-release --target wasm32-unknown-unknown` exited with status code exit status: 101

that's without verbose unfortunately. I just flipped some dependency versions so am executing a different build at the moment

I more wanted to flag that its not clear as a user what accommodations bevy_cli is making to the project, especially when it comes to things like the getrandom situation (which I know is a headache all over)

[silk delta]

It looks like the getrandom wasm_js feature isn't getting applied for feature build

because that's what the error seems to state

[shrewd monolith]

Hm, it seems like fixing that (i.e. communicating what the CLI's doing) would not be easy. Compilation is very noisy, and so are the flags required to fix getrandom (as well as the multi-threaded flags). You can enable verbose output of course, which provides all that information, but then you get even more noise.

[limber wedge]

will try to investage tomorrow, maybe you have already configured getrandom_backend but only for the release profile?

[molten merlin]

yep, that is what is going on for sure.

[molten merlin]

I don't personally need an investigation, so don't worry about that. I have effectively solved it for my own project by configuring the getrandom situation multiple times.

it was weird to see a difference between debug build and release build with no other changes

[pale viper]

That error makes me think you might be missing the wasm_js feature for getrandom. Could you please check that your Cargo.toml has something like this:

getrandom = { version = "0.3", features = ["wasm_js"] }

[molten merlin]

I've already fixed it yeah. but the point is that it was working in dev, and not in release

so it only failed in CI, despite it working while I was developing it

(I later confirmed it down to dev working locally and release failing locally)

[pale viper]

Hmm. If you have a repo + commit, I can test it out, but you were compiling getrandom v0.3.4. In that version they fixed it so you no longer need --cfg getrandom_backend="wasm_js". The Bevy CLI's getrandom feature is only useful when compiling an older version

[limber wedge]

yeye i know ment more so we can fix it for folks who are not that deep into it like you are

[molten merlin]

https://github.com/ChristopherBiscardi/bevy-jam-7/commit/109ae406e461372c606c9af447816725508c81dd is the fix commit.

worth noting that the repo has bevy_rand, with getrandom 0.4, bevy with getrandom 0.3.x, and a geo's main branch, which brings a getrandom dep up from 0.2 to 0.3.

[pale viper]

I’ll take a look, thank you!

[molten merlin]

sorry its not more minimal 🙏 I'm trying to avoid getting lost in side questing again this jam 😭

[pale viper]

All good, thanks for letting us know in the first place!

[vast vine]

I just updated bevy_cli to the latest commit and now when I do bevy run --example example_name it tells me No binaries found! which doesn't make sense to me because it worked before and it works fine when I do cargo run --example example_name

I went back to the last release just to make sure and it does work as expected

[limber wedge]

yea should be fixed with https://github.com/TheBevyFlock/bevy_cli/pull/636 i think

its the latest pr that got merged that broke that i assume

[limber wedge]

i think your case is because you have multiple getrandom crates in your dependency tree, and the feature "wasm_js" for getrandomv3 is only enabled by bevy_egui, which in turn is only enabled by the inspector_egui feature.

You set these features like this:

[features]
# Default to a native dev build.
default = ["dev_native"]
inspector_egui = ["dep:bevy-inspector-egui"]
free_camera = ["bevy/free_camera"]
webgl2 = []
dev = [
    # "free_camera",
    "inspector_egui",
    # Improve compile times for dev builds by linking Bevy as a dynamic library.
    "bevy/bevy_dev_tools",
    "bevy/bevy_ui_debug",
    # Improve error messages coming from Bevy
    "bevy/track_location",
]
dev_native = [
    "dev",
    # Enable asset hot reloading for native dev builds.
    "bevy/file_watcher",
    # Enable embedded asset hot reloading for native dev builds.
    "bevy/embedded_watcher",
]

And with the release profile its set to run with default-features = false so you end up without the wasm_js feature.

its sad that we dont catch this and give you the toml snipped we for sure can improve the detection on our side so it feels less random

[molten merlin]

Yeah, at the point I posted the message I knew a few things:

• there were multiple getrandom inclusions (had already done some work to trim it down from 3 to 2 by git-dep'ing geo)
• bevy_cli was doing "something" (later confirming that this was only relevant for v2)
• it worked in dev and not release
• bevy_new_2d trends towards a decent amount of config (I based my project on the Cargo.toml/gh actions from the template so I could answer other people's questions if they ran into things)

Additionally, when running cargo tree -i getrandom, bevy-inspector-egui hides in what is (somewhat generously with a smaller font size) 7 pages of terminal output that is all bevy_* crates that cause rand to be included, so to find it, it has to be a diff on two runs of cargo tree with dev/release features

[molten merlin]

for me personally, I think either one of these would work:

• knowing the cli isn't doing "something" means the problem is squarely in my court (ie: it is a problem with my config for sure) and I can dig and know I'll find the answer
• bevy_cli giving more information, like you suggested

[limber wedge]

The -e features option helps a lot cargo tree -e features -i [email protected] --target wasm32-unknown-unknown

[limber wedge]

yea 100% i think its just worst case scenario that we show the snippet sometimes and not in your case giving you the feeling of "oh but everything is correct in my config"

so i would like to do better there

[foggy basin]

If I remember correctly, if the CLI is doing stuff like this automatically, it will provide an info level log about it
So it should be visible without verbose mode

[pale viper]

@limber wedge I'm a bit confused with your response to https://github.com/TheBevyFlock/bevy_cli/pull/636#discussion_r2785601702. My point was:

• cargo build --examples --all-features does not work in Bevy's repository, due to incompatible features
• bevy build --examples should not automatically add --all-features, since users cannot turn it off

[limber wedge]

what do you mean with incompatible features?

[tardy cove]

zstd_c vs zstd_rust is an example

It should be either or, not both

[limber wedge]

ye i didnt think about the fact that you cant turn it off that is for sure dumb lol i will remove it

or if you have time feel free to do it im busy the next few days

[atomic ravine]

when trying to run our game with bevy build web -U multi-threading I get this error

thread 'main' (3205289) panicked at /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasm-bindgen-cli-support-0.2.106/src/interpreter/mod.rs:209:17:
__rustc[dde6fad95d619c59]::rust_begin_unwind: Condition failed: `address % width == 0` (4 vs 0)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: failed to run wasm-bindgen, trying to find automatic fix...
error: command `wasm-bindgen --no-typescript --out-name bjam --out-dir /home/user/bjam/target/wasm32-unknown-unknown/web --target web /home/user/bjam/target/wasm32-unknown-unknown/web/bjam.wasm` exited with status code exit status: 101

interestingly, when I add --release everything builds without errors but when I try running the result in the browser (either with bevy run or uploading to itch with SharedArrayBuffer support enabled), the page errors out with

bjam.js:2481 Uncaught TypeError: [object Int32Array] is not a shared typed array.
    at Atomics.waitAsync (<anonymous>)
    at imports.wbg.__wbg_waitAsync_8afec80ffd213eca (bjam.js:2481:29)
    at bjam_bg.wasm:0xff8bca
    at bjam_bg.wasm:0x139878b
    at bjam_bg.wasm:0x1cc2766
    at bjam_bg.wasm:0x1d80aca
    at wasm_bindgen_87e90c97c2bdaa7b___convert__closures_____invoke___wasm_bindgen_87e90c97c2bdaa7b___JsValue_____ (bjam.js:316:10)
    at real (bjam.js:232:20)

any pointers would be appreciated

[shrewd monolith]

The second error means your CLI must be out of date -- or at least it doesn't include the commit that fixed that error.

[limber wedge]

Yea definitely update the cli version otherwise newer wasm-bindgen versions cause problems

[atomic ravine]

should I use the latest commit? I'm using the one recommended by the readme bevy 0.1.0-alpha.2

[limber wedge]

I would update to: d6b5864b7230ecde852fe8f1e26d6c3689270e90

[atomic ravine]

that did it! thank you all, now my build isn't crackling woo!

[pale viper]

I'll fix it!

Yeah, I figured we were talking about different things when you pushed 7517b24

[limber wedge]

Yep i thought you ment that the problem is that you get a compiler error when compiling with —all-features and not that you maybe dont want to compile with all features since that doesn’t make sene in all cases

[pale viper]

Glad we’re on the same page now 😄

[karmic musk]

Hey, can anyone take a look at https://github.com/TheBevyFlock/bevy_cli/pull/733?
It just needs a few straightforward changes and it should be ready to merge

[foggy basin]

Project goals related to this working group:

• CLI App Templates
• CLI Web App Building
• Bevy Code Linting

[limber wedge]

This is very exciting

[foggy basin]

Should we create separate, new design documents for each of these goals?
From what I have gathered so far, cart wouldn't be a fan of upstreaming everything in one go.
In that case, I think it makes sense to capture the motivation, problem space and what's implemented in the prototype in a fresh design document dedicated from the particular goal.
Then it's easier to onboard new contributors and to tackle each goal separately (and hopefully faster in the end)

[limber wedge]

i personally think we have quite a lot already for cart to look at so i rather wait his initial feedback and then go from there

[snow linden]

Hello, I would like to pitch in for the "CLI Web App Building" goal

anything need doing?

Seems like it's lacking a design document.

[rocky oxide]

Yes, a modest design doc would be great.

[snow linden]

I'd love to help with this. I have some expirence with building for the web and design doc writing, but probably can't do it all on my own.

[rocky oxide]

The points I want are:

1. Why is this needed? Why do we care about web and why is it hard to build for web?
2. What (rough) steps would this tool do?
3. Why should we ship this as a CLI? What alternatives exist?
4. How should that CLI be structured and built?
5. Future work: how might this be extended? Will we eventually care about supporting other complex-to-build platforms with this same tool? What about just building for standard platforms?

[foggy basin]

So do we want a separate design document for the three CLI goals?

[foggy basin]

I also have many thoughts on this, based on the work we already did on the prototype and what we heard from users so far

[rocky oxide]

Yes please

[snow linden]

sweet, maybe we can chat about it and start a new doc?

[foggy basin]

Sure! it's late for me now, but let's talk about it tomorrow :)
(Or, if you already have something in mind feel free to DM me already and I'll get back to you later)

[analog fern]

bevy_cli

I've left this as a single working group for now, as it has shared culture and history. May split things out over time if that seems valuable

[limber wedge]

Something to keep in mind is how we test the cli. Currently we severely lack tests. We could take inspiration from cargo

And not that important just now but i think maybe switching away from the derive to the functional approach in clap could reduce our code duplications a lot

[foggy basin]

I have also been thinking about that. It might make it easier to apply defaults from the config file which are then overwritten by the CLI flags

[foggy basin]

Yea testing is tough. There are many special cases to consider so better test coverage would be great.
The problem is that testing often involves compiling a bevy app from scratch, so they can be quite time intensive

[pale viper]

Agreed, I think Cargo’s test infra is a great starting point for us: https://doc.crates.io/contrib/tests/writing.html

[pale viper]

We might be able to offload the brunt of the longer tests to merge queues, and only run quicker tests on PR updates

[limber wedge]

Yes and i would imagine that the big cost can be cached

[pale viper]

We might be able to make them share a target directory? Though the target lock might reduce test parallelism

[pale viper]

Is it possible to mix functional and derive at all? I don’t mind pure functional, but it might be more intimidating to new contributors

[limber wedge]

Yes you can mix derive and builder iirc

[foggy basin]

True, that could be a good middle ground!

[pale viper]

Found this: https://docs.rs/clap/latest/clap/_derive/index.html#mixing-builder-and-derive-apis

[rigid bluff]

I get the same message when trying to run bevy run web.

Anyone know a fix ?

[limber wedge]

You have to enable the wasm_js feature for getrandom

[target.'cfg(all(target_family = "wasm", any(target_os = "unknown", target_os = "none")))'.dependencies]
getrandom = { version = "0.3", features = ["wasm_js"] }

[vast vine]

wasn't that something that the cli was supposed to automatically do?

[limber wedge]

No we do not set the feature automatically because thats not that easy iirc

We set the rustflags and there should be a code suggestion that we provide

[foggy basin]

Unfortunately you can't do it for transitive dependencies without modifying Cargo.toml
And there were strong opinions against modifying Cargo.toml automatically (and I still think this is a good decision)
As Lil said we automatically handle the rustflag that needs to be set in addition to the feature and we provide means to automatically enable features for web builds when needed

I originally tried an approach to automatically activate the feature via --config flags, but unfortunately there are some differences on how --config behaves compared to manually modifying the Cargo.toml

[vast vine]

Right, that makes sense, I guess I had misunderstood what it was doing

[foggy basin]

That's fair, maybe it is not well communicated.
And originally, handling everything automatically was the plan

I just wish we had a dedicated wasm32-web target, it would make a lot of things easier

[vast vine]

tbf, I've just been using it for a while and haven't really looked at the docs in a long time so that's definitely on me

[foggy basin]

Nobody looks at docs for CLI tools. If it doesn't explain itself, it's a bug in my view :D

[vast vine]

So, here's a test case for you that I can't figure out. We recently merged examples/large_scenes/bevy_city in bevy. It uses rand 0.10. I'm trying to use the cli like this bevy run --release -p bevy_city --features bevy/webgpu web Which first gave me the instructions about adding the cfg block, but it suggested me the version for getrandom 0.2. I added it to the cargo.toml of bevy_city and now I get

error: could not compile `getrandom` (lib) due to 4 previous errors
warning: build failed, waiting for other jobs to finish...
warning: failed to run cargo, trying to find automatic fix...
error: command `cargo build --config profile.web.inherits="dev" --config profile.web-release.inherits="release" --config profile.web-release.opt-level="s" --config profile.web-release.strip="debuginfo" --package bevy_city --features bevy/webgpu --profile web-release --target wasm32-unknown-unknown` exited with status code exit code: 101

I tried adding the snippet you shared just above for getrandom 0.3 and it also didn't work

and if I use cargo tree I apparently have 3 versions of getrandom 🙃

All I did was add latest rand to that specific example

@silk delta ^ (IIRC you wanted to be pinged on anything rand/getrandom related)

So yeah, not sure how to fix it and what the cli could do to help here

[silk delta]

@vast vine rn, there will be three versions of getrandom for bevy, but there is movement to see ring move to v0.4 at some point (ring is on v0.2) and winit dropping ahash next version means it will no longer need v0.3

But lots of things in the ecosystem might reference some version other than the latest

[molten merlin]

there's a section in the docs that tries to cover multiple getrandoms: https://thebevyflock.github.io/bevy_cli/cli/web/getrandom.html#what-it-does

no idea if it will work for you though... I was able to get my jam entry down to 2 getrandoms and configured 0.4 through bevy_rand and 0.3 manually

[limber wedge]

what version of the cli are you using?

there used to be an issue that made you depend on a specific wasm-bindgen version

iirc if you update to the latest main branch examples should work and this issue shoudl be gone

[vast vine]

I installed it from main last night

[vast vine]

Okay, so, I had to do this for it to work

[target.'cfg(all(target_family = "wasm", any(target_os = "unknown", target_os = "none")))'.dependencies]
getrandom = { version = "0.3", features = ["wasm_js"] }
getrandom_02 = { version = "0.2", features = ["js"], package = "getrandom" }
getrandom_04 = { version = "0.4", features = [
  "wasm_js",
], package = "getrandom" }

Essentially, I just copied what your link does and added it for 0.4

[limber wedge]

a nvm then ^^

[vast vine]

Alright, well, it compiled but I'm hitting an unreachable 🙃

[foggy basin]

What a mess lol
But glad you got it to work!
We should adjust the CLI output so it suggests that directly

[sand plover]

Not 100% but saw this and maybe it’s relevant to your problem? #engine-dev message

[vast vine]

Well, kinda but not exactly, it would just make it a bit less messy

[shrewd monolith]

Okay I put together a little PR that provides a loading bar for the default HTML template. I really felt the lack of a proper indicator this jam, with lots of games taking long enough for me that I snooped the browser console to make sure nothing went wrong!

Obviously the effort here is going to be focused on upstreaming with the new goals, but I just wanted to get the ball rolling.

[foggy basin]

I think the issue is two fold: (1) no sense of progress with the loading indicator so you don't know how long it's supposed to take and (2) no proper error handling, so a long loading screen can also mean that something is broken

[shrewd monolith]

A followup I'm interested in doing is catching and displaying Rust panics, which I may have mentioned before. It should be possible, since panics will generally end up throwing an exception.

[foggy basin]

I tried both before (loading progress and displaying rust errors) but didn't find a good solution yet, so I'm happy to accept PRs for both!

[foggy basin]

I left some (minor) comments.
Thanks for taking the time!

One thing I wanted to do for a long time now is to split some things from index.html into smaller JS files that are imported, sort of as a "library". And then have a bevy init web command that copy pastes the default files into a web folder. That way a user could more easily customize our defaults while having access to some nice utilities for better user experience

[shrewd monolith]

Oh yes that would be really nice.

[foggy basin]

In general, the bundling story is the weakest point of the web CLI prototype IMO.
That's something I want to mention in the design document as well.
Including the Bevy app in a larger web application is a pain with the current state of things

[silk delta]

One thing I'm going to try with bevy_rand is have the wasm_js feature apply to all getrandom versions. If I can have this work, then perhaps it will simplify things greatly for configuring Web WASM. If someone wants, once I push the branch, they could test it with their setup and confirm that it works

[silk delta]

Here is the PR, which should provide the necessary enablement without needing to stuff your Cargo.toml with lots of config

[silk delta]

Bah, it doesn't have the effect I want. I'll just have it work as part of a compat feature, but otherwise, some cargo toml config still required for transitive deps :<

[twilit dew]

friends, the CLI is running into an oops on my side (bleeding edge as always )

I'm compiling for webgpu with

[package.metadata.bevy_cli.unstable]
web-multi-threading = true

and it works, as long as I don't have a global ~/.cargo/config.toml

but I use this: https://gist.github.com/janhohenheim/5731c11e91736bab5e9ef58c2a982c36

gives me

[twilit dew]

Update: this section is the culprit

[target.wasm32-unknown-unknown]
rustflags = [
    # Improve performance
    "--cfg",
    "web_sys_unstable_apis",
    "-Ctarget-feature=+sign-ext,+nontrapping-fptoint",
    # Compile faster
    "-Zshare-generics=y",
    "-Zthreads=8",
]

update2: removing these lines fixes it

    "--cfg",
    "web_sys_unstable_apis"

hmm I guess the target-features are also no longer needed

[twilit dew]

oh, forgot to mention: cargo 1.95.0-nightly (efcd9f586 2026-01-23)

[pale viper]

Hmm, I’m not familiar enough with web-sys to diagnose this

Maybe @foggy basin has an idea?

[trail shale]

latest wasm-bindgen family release had issues...
https://docs.rs/web-sys/0.3.85/web_sys/struct.WebGl2RenderingContext.html#method.tex_sub_image_3d_with_video_frame exists in 0.3.85, but not on the 0.3.86.
I already raised 2 issues I noticed https://github.com/wasm-bindgen/wasm-bindgen/issues/4973 (building glow and winit in wasm) and https://github.com/wasm-bindgen/wasm-bindgen/issues/4978 (building wgpu with webgpu support), seems you found a third one

so... either pin web-sys and know that it will break for more people later on while you're stuck on old versions, or report an issue to them 😄

they regenerated the bindings and its now called https://docs.rs/web-sys/latest/web_sys/struct.WebGl2RenderingContext.html#method.tex_sub_image_3d

but it's part of web_sys_unstable_apis and I think those don't follow semver, so you may be out of luck there

[twilit dew]

why would they do that in a patch ;-;

even if it's unstable

[trail shale]

I don't speculate on other large project maintenance practices, we all have our own issues... but yeah no semver for you here

[foggy basin]

Did we change anything here?

[limber wedge]

No but building with the newest wasm-bindgen version only works when you are using main

Due to the new required linker args iirc

[neat oasis]

Hello, trying to allow a lint for a specific struct, but running into an extra warning:

I got code like

#[derive(Debug, Message)]
pub struct ModLoadErrorMessage(pub Report);

and I get the suggestion from bevy lint:

warning: defined a message without a `Reflect` implementation
  --> game/src/mods.rs:58:1
   |
58 | pub struct ModLoadErrorMessage(pub Report);
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
note: `Message` implemented here
  --> game/src/mods.rs:56:17
   |
56 | #[derive(Debug, Message)]
   |                 ^^^^^^^
   = note: requested on the command line with `-W bevy::missing-reflect`
   = note: this warning originates in the derive macro `Message` (in Nightly builds, run with -Z macro-backtrace for more info)
help: `Reflect` can be automatically derived
   |
58 + #[derive(Reflect)]
59 | pub struct ModLoadErrorMessage(pub Report);
   |

I can't implement reflect for this message because Report is external non-reflect, and it wouldn't be useful to reflect it anyway, so I tried to ignore it by following the docs:

added #![cfg_attr(bevy_lint, feature(register_tool), register_tool(bevy))] to my main.rs, and put #[cfg_attr(bevy_lint, allow(bevy::missing_reflect))] on my struct like so:

#[derive(Debug, Message)]
#[cfg_attr(bevy_lint, allow(bevy::missing_reflect))]
pub struct ModLoadErrorMessage(pub Report);

it silenced the reflect warning, but instead a new warning appeared:

warning: allow(bevy::missing_reflect) is ignored unless specified at crate level
  --> game/src/mods.rs:57:29
   |
57 | #[cfg_attr(bevy_lint, allow(bevy::missing_reflect))]
   |                             ^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(unused_attributes)]` (part of `#[warn(unused)]`) on by default

I can confirm that the bevy lint processes the attribute, because if I do deny the warning (#[cfg_attr(bevy_lint, deny(bevy::missing_reflect))]) I both get a warning about an unused attribute as well as an error for denied lint:

warning: deny(bevy::missing_reflect) is ignored unless specified at crate level
  --> game/src/mods.rs:57:28
   |
57 | #[cfg_attr(bevy_lint, deny(bevy::missing_reflect))]
   |                            ^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(unused_attributes)]` (part of `#[warn(unused)]`) on by default

error: defined a message without a `Reflect` implementation
  --> game/src/mods.rs:58:1
   |
58 | pub struct ModLoadErrorMessage(pub Report);
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |

So I assume it's the cargo not recognizing the attribute somehow?

[neat oasis]

system info:

rustup 1.28.2
cargo 1.93.0 (083ac5135 2025-12-15)
bevy 0.1.0-dev
bevy_lint v0.6.0
---
Fedora Linux 43 (KDE Plasma Desktop Edition) x86_64
Linux 6.18.12-200.fc43.x86_64

stable toolchain

[rocky oxide]

https://bsky.app/profile/rustnl.bsky.social/post/3mg5u4orua32y

RustNL (@rustnl.bsky.social)

** Speaker announcement ** At RustWeek 2026, Alona Enraght-Moon will talk about the complexities involved in writing your own tools that need information from deep inside the Rust compiler.

Info & tickets: buff.ly/9aHwJFE

See you in Utrecht May 18-23, 2026!

@alona.page
#rustweek2026 #rustlang

Bluesky · Mar 3, 2026, 1:17 PM

[foggy basin]

Thanks, I missed that in the list of talks!

[pale viper]

Oops, that's a bug! I bet it's because we set @crate_level_only = true for that lint
https://github.com/TheBevyFlock/bevy_cli/blob/95a0d3b0786881338380d250ce0aefc9c6114a80/bevy_lint/src/lints/restriction/missing_reflect.rs#L75

[pale viper]

I just opened a PR that should fix it! If you have a chance, could you try building and testing https://github.com/TheBevyFlock/bevy_cli/pull/752 on your code and see if it's fixed for you?

[neat oasis]

will try with cargo install --git https://github.com/TheBevyFlock/bevy_cli --branch missing-reflect-crate-level-only --locked bevy_lint

huh, can't compile bevy_lint with this command even after rustup default nightly

[limber wedge]

Would be a neat feature to build the linter from branches too instead of only releases and main

[limber wedge]

You would have to use:

rustup toolchain install nightly-2026-01-22 \
    --component rustc-dev \
    --component llvm-tools

And then install with:

rustup run nightly-2026-01-22 cargo install \
    --git https://github.com/TheBevyFlock/bevy_cli.git \
    --branch missing-reflect-crate-level-only \
    --locked \
    bevy_lint

[neat oasis]

yeah, this works

I no longer get a warning about unused attr

[limber wedge]

🥳

[pale viper]

Awesome! I just merged the PR, so you should be good to run the main branch of the linter :)

[neat oasis]

nice, thanks!

[halcyon saddle]

Hi all, please redirect me if needed. I've been trying to improve my web targeting story in a multithreaded app. I have the mainline bevy_cli from a few days ago, am using bevy r web -U multithreading along with the cargo web-multi-threading = true flag, have the nightly toolchain, etc... project builds and launches, and bevy_seedling works, but std::thread::spawn still panics.

So, in what sense is multithreading actually supported in bevy_cli? I tried building for wasm32-wasmp1-threads but js_sys doesn't exist for it...

I see that bevy_seedling doesn't even seem to launch threads in wasm32 builds. It uses "contexts" instead which seem to tie in with the bevy project template's wasm/restart-audio-context.js.

So... what big chunk of get-a-clue-about-web-dev am I missing here? Do I need to make a "context" instead of a thread?

[shrewd monolith]

std::thread::spawn cannot be used as a means to spawn threads on the web.

bevy_seedling runs audio on a separate thread — that of the web audio graph

If you want arbitrary threads, look into web workers

they behave essentially like OS threads, but the process of creating them is different

there are a few crates floating around that abstract over them, such as gloo_workers i believe

(though note that gloo is basically abandoned, so might not be the best to rely on)

[halcyon saddle]

OK, that's the clue and it answers my question. Thanks!

[rigid bluff]

Hello, since compile times are one of the major pain points of bevy and rust in general, I am very interested in the potential of this issue: https://github.com/TheBevyFlock/bevy_cli/issues/213

Is there an idea of how it would work and what it should include ? Maybe a stepping stone ?

[limber wedge]

imo there is no clear winner for all platforms so this would just lead to a lot of code for something that is imo best documented or just part of a template. i use @twilit dew 's config that he shared once:

# Yoinked from: https://github.com/janhohenheim
[unstable]
codegen-backend = true

[profile.dev]
# Compile using cranelift for massively faster compilation
codegen-backend = "cranelift"
# If you want to attach a debugger, set this to true
debug = "line-tables-only"

# Consider compiling deps with cranelift if you want cold-compilation to be faster
[profile.dev.package."*"]
codegen-backend = "llvm"

# cranelift is `panic = abort`, so you need to compile with llvm to get `#[should_panic]` working
[profile.test.package."*"]
codegen-backend = "llvm"

# Disable cranelift for release profile
[profile.release]
codegen-backend = "llvm"

# cranelift cannot build wasm32-unknown-unknown out of the box
[profile.web]
codegen-backend = "llvm"

[target.x86_64-unknown-linux-gnu]
rustflags = [
    # Compile faster
    "-Zshare-generics=y",
    "-Zthreads=8",
]
rustdocflags = [
    # Compile faster
    "-Zshare-generics=y",
    "-Zthreads=8",
]

[target.wasm32-unknown-unknown]
rustflags = [
    # Improve performance
    "--cfg",
    "web_sys_unstable_apis",
    "-Ctarget-feature=+sign-ext,+nontrapping-fptoint",
    # Compile faster
    "-Zshare-generics=y",
    "-Zthreads=8",
]
rustdocflags = [
    # Compile faster
    "-Zshare-generics=y",
    "-Zthreads=8",
]
``` and that works really really well for me (linux).

[halcyon saddle]

BTW, if you integrate this, please amend this to:

[profile.'not(cfg(target_os = "macos"))'.dev]
codegen-backend = "cranelift"

since cranelift is broken on macOS nightly (https://github.com/bevyengine/bevy/issues/20785)

[rigid bluff]

Rather than lock into the best config, I imagined it would offer choices, and some are pretty universal like dynamic lib bevy and nightly toolchain

[opaque anvil]

Shouldn't it be -Zthreads=0, so that it adapts to the user's hardware?

[foggy basin]

I still think this would provide value.
Compared to a project template, it offers multiple advantages:

• Interactive (you can e.g. ask the user if they want to work with stable or nightly)
• User-wide configuration instead of project-wide configuration. Not everyone can / wants to install a custom linker, so a project config which would enforce that would prevent those people from using the project effectively.
• Automatic tool setup. E.g. installing the nightly toolchain, installing cranelift, installing mold/wild

[rigid bluff]

I agree, we should start small with perhaps only nightly setup, then build upon it with more capabilities

[foggy basin]

First iteration could just apply @twilit dew's config, as that seems to be the current state of art (at least for Linux).
We would need to think about questions like what we do if a config already exists, e.g. overwrite / merge.
Then in later iterations we could add the interactive questions and automatic tool installation.

Personally, I would happily accept such contributions. Just keep in mind, when upstreaming this might not be in scope or there might be vastly other opinions on how to do this by the maintainers

[limber wedge]

Im not opposed to it i am just concerned that it adds a lot of maintenance burden on us. We constantly need to monitor all these options to check that we still install / configure them correctly and i imagine that the users who can make the interactive decisions already use / know how to do this / have their own preferences.

Imo we should focus more on how to configure bevy for these use cases (dyn linking for example)

[foggy basin]

I think right now the maintenance burden is actually higher.
When there is a new compile configuration that's faster, we have to change the config in every template and users have to manually copy them into their old projects / user config.
With a dedicated command, we can just update it once in the CLI and then users can just run the command again to update.
Templates wouldn't need to include it at all, since the user configuration applies to all Bevy projects

[foggy basin]

Yea the Bevy configuration is kinda separate, because it's done in the Cargo toml instead. So that cannot be done on a user level

[foggy basin]

For example, the minimal template currently has a different configuration than the 2d tempalte

[limber wedge]

Its definitely less work for the users im also wondering if it would maybe hide too much. For example i use cranelift and you have to keep in mind to re add the component when updating rust version. Or some tests behave differently with cranelift than without

[foggy basin]

That's fair, we would have to quite transparent which tools we set up and which commands are run to do so

[limber wedge]

Tho i guess we could start easy (just choosing nightly or stable) since there used to be discussions about web requiring nightly anyway

[foggy basin]

One good thing is that it could be nicely isolated, so it could be upstreamed completely independently of the other stuff (or not at all if it doesn't turn out to work well)

I do like the vision for the onboarding of new users though,
Instead of "install nightly, copy this random file to this location, remember to comment out/on these lines depending on your setup" you can just say "run bevy init fast-compiles"

[limber wedge]

bevy init slow-compiles

Yea that would be nice. Maybe worth just checking how it feels

And how stable it is

[foggy basin]

I see your points though. Maybe worth to check the opinion of maintainers / other contributors first.

[twilit dew]

From my perspective, I need to constantly monitor that config anyways, since I use it every day. And as you say, I don’t bother updating it on every single repo that started using the same config because it’s annoying. So I personally would have less maintenance burden if I could just PR any updates on bevy_cli and be done with it

[twilit dew]

Would that also install the wild linker for you? I assume yes, since it’s a simple cargo install

[foggy basin]

That would be my expectation (but not a must have for a first iteration).
Would probably be easy, as we already have install utilities anyway

[silk delta]

wild linker doesn't perform as well if your drives are formatted with BTRFS

So can be situational

[opaque anvil]

Lmao I've just migrated to btrfs last week 😔
How can an FS slow down a linker?

[vague brook]

btw shouldn't "-Zthreads=8", be =0 for auto-detection of the system available parallelism ?

[foggy basin]

I think it was a deliberate choice since at some point the added parallelism doesn't scale well anymore? Or might have been to conserve system resources for other things.
@twilit dew do you remember?

Jan's config is for a high-end system though so we might need to make adjustments for a general purpose config

[limber wedge]

yes 100% this is just the config i saw once, possible that its not even up to date. Was more ment as an idea not that we should 100% use that

[foggy basin]

The link here has the up to date one

[twilit dew]

It runs into Amdahl's law after 8

[twilit dew]

Bingo

[twilit dew]

Not really, no at least not to my knowledge

Worth noting I use the same config on my crappy university computer

[foggy basin]

@shrewd monolith I'm very sorry, I totally missed your replies on the loading indicator PR!
I left a response now :)

[trail shale]

has there been experiments in the CLI to split the wasm file into several smaller ones loaded on demand?

dioxus and leptos both do it, but differently I think but didn't look too much into it
leptos add a #[lazy] macro that replaces functions with an async variant that triggers the wasm load on their first call
dioxus split the wasm binary by routes called

I'm guessing / hopping we could do something similar to dioxus by splitting by schedules?

[foggy basin]

I don't think so, I wonder how that would look like for Bevy

Sounds like something to do after upstreaming though :)

But binary size will definitely need more research I recon. It's quite bad right now

[trail shale]

or sounds like something highly experimental that would be better tried out of tree 😄

but yeah, it depends if it needs changes in Bevy itself

I don't know

the leptos way would need Bevy changes, not sure about the dioxus way

as far as I understand it it's

• build the wasm binary
• parse it and split it depending on when functions are called
• add a wrapper that loads the correct bin on demand

[foggy basin]

Interesting that it works on the final wasm binary, that would be quite cool without any code changes.
But I wonder how well that function analysis works for Bevy's architecture

[trail shale]

yup me too

I hope there's an easy split between the ecs and renderer init on one side, and all the renderer usage on the other

for many things you need the types at init time, but the functions dealing with them only later, like sound playing, image reading, gltf parsing, ...

[foggy basin]

Wasn't there also a problem with dead code analysis, that it's difficult for the Rust compiler to detect what's not used so the binary size is large when you don't disable as many features as possible?
We might have similar problems with this approach

[trail shale]

the issue with dead code analysis is that systems are still in the schedule even if they won't match any entity

it shouldn't be an issue if we split by schedule

[foggy basin]

Ah I see

How easy would it be to detect schedules in a wasm binary?

[trail shale]

lots of unknowns 😄

it's a big experimental project, but it could blow away all issues with wasm binary size if it works

[foggy basin]

Yea definitely sounds high-value, especially if it works "out of the box"

I wonder though, what happens when a chunk is not loaded yet when you need it? :D

[civic dirge]

may i get a review on https://github.com/TheBevyFlock/bevy_cli/pull/763 ?

[foggy basin]

I'll leave it open for a day or so in case someone else also wants to chime in, but looks good to me. Thanks!

[limber wedge]

You are german? @foggy basin

[limber wedge]

I have a long train ride tomorrow so i can test it and then merge

[foggy basin]

Yes

[rocky oxide]

I am particularly interested in feedback from members of this group (cc @twilit dew), as it gives detailed advice on what good project setups look like

[foggy basin]

Sorry, I forgot to press the button, merged now!

[snow linden]

@foggy basin if i'm using the cli to serve a web app, how do i use the https asset loader? what url do i put in?

will it host an ./assets directory?

[foggy basin]

Yes, the assets directory is served, but we don't support local https yet. I think there's an issue for that

[snow linden]

yep, got that working. i think you should add something about assets to the docs

[opaque anvil]

Can someone take a look at https://github.com/TheBevyFlock/bevy_cli/pull/733 pretty please 🥺

I've tested it with the proposed fixes applied and it just works

[potent lotus]

Seems like this waits for the author to react on the review.

[opaque anvil]

I think the author's gone lol

Should I open a new PR?

[potent lotus]

BD103 is an active user here. I don't want to tag in case your comment on github already pings him but you can tag him and offer to do that ofc

[limber wedge]

I can apply the fixed and merge them today. I think its just rather slow since none of us really uses nix

[opaque anvil]

thank you 😭

[limber wedge]

We are all rather inactive since we are waiting on upstreaming in some form

[opaque anvil]

Oh are there recent talks to upstream this? Feels like it's not gonna happen in a long time tbh

[limber wedge]

Not recently. Its mostly dependent on Cart and he had more important work to do with bsn! But there exists a goal at least now

[karmic musk]

Hi, can I have some feedback on: https://github.com/TheBevyFlock/bevy_cli/pull/776?

[karmic musk]

Now that it has two approvals, any chance of it being merged anytime soon? No pressure and thanks for the reviews.

[karmic musk]

Is there a way to benefit from the getrandom autoconfig while using a custom profile?

When I run:

bevy build --profile ci web

I get:

info: automatically configuring `getrandom` web backend
info: compiling to WebAssembly...
...
warning: You have to enable the `getrandom` web feature in your Cargo.toml:

The error doesn't happen when I omitted the --profile ci.

[limber wedge]

The issue is that we cannot enable this feature for you and i imagine without this profile another dependency already enables it?

We only set the required rustflags

[karmic musk]

Hmm, but the rustflags are supposed to be independent of the profile right?

[limber wedge]

they should be, you could check with bevy build --profile ci web -v

but i imagine that your "ci" profile just does not enable the feautre and we do not enable features for you

(since this can not be done via cli flag)

[karmic musk]

Hmm, I didn't do anything special for my dev, web, release and web-release profile though, so I'm not sure where the difference is coming from.

[karmic musk]

I got:

debug: running: `cargo build --config profile.web.inherits="dev" --profile ci --target wasm32-unknown-unknown`
debug: with env: RUSTFLAGS= --cfg getrandom_backend="wasm_js"

So maybe it's an inheritance issue?

I tried to make ci inherit it too, but no dice:

$ bevy build --config 'profile.ci.inherits="web"' --profile ci web -v
info: automatically configuring `getrandom` web backend
info: compiling to WebAssembly...
debug: running: `cargo build --config profile.web.inherits="dev" --config profile.ci.inherits="web" --profile ci --target wasm32-unknown-unknown`
debug: with env: RUSTFLAGS= --cfg getrandom_backend="wasm_js"

Also tried --config 'profile.ci.inherits="dev"' but no dice either.

[limber wedge]

most the time this happens if you dont use some crates in this profile. Most likely one of your dependencies enables this feature that is not used in ci

is the repo public?

[karmic musk]

I'll try to make a minimal repro. My profile configs are basically copied straight from the bevy_new_2d repo: https://github.com/TheBevyFlock/bevy_new_2d/blob/a5f5bd77c697533b7487dfb2039a8bf2e6a81cde/Cargo.toml#L78-L115

[karmic musk]

Yeah reproduced this with the bevy_new_2d template:

$ bevy new -t 2d repro_2d
$ cd repro_2d
$ bevy build --profile ci web -v
...
error: can't compile for wasm32-unknown-unknown: Support for this target has not been implemented yet

error: could not compile `repro_2d` (bin "repro_2d") due to 1 previous error

[limber wedge]

let me check!

[limber wedge]

hm i can compile this without any issues

[karmic musk]

huh, that's bizarre....

with the --profile ci?

[limber wedge]

are you using cranelift?

[limber wedge]

i use this config.toml ```toml

Yoinked from: https://github.com/janhohenheim

[unstable]
codegen-backend = true

[profile.dev]

Compile using cranelift for massively faster compilation

codegen-backend = "cranelift"

If you want to attach a debugger, set this to true

debug = "line-tables-only"

Consider compiling deps with cranelift if you want cold-compilation to be faster

[profile.dev.package."*"]
codegen-backend = "llvm"

cranelift is panic = abort, so you need to compile with llvm to get #[should_panic] working

[profile.test.package."*"]
codegen-backend = "llvm"

Disable cranelift for release profile

[profile.release]
codegen-backend = "llvm"

cranelift cannot build wasm32-unknown-unknown out of the box

[profile.web]
codegen-backend = "llvm"
``` so this fails for too. but this is because i dont override the codegen-backend for the ci profile

so if i add [profile.ci] codegen-backend = "llvm" it compiles

[karmic musk]

omg thanks for pointing this out!!! I had cranelift enabled which isn't supported in wasm

what is especially dumb of me is that I know that cranelift doesn't support wasm and I still put profile.ci.codegen-backend = "llvm" in my config for some reason 🤦‍♂️🤦‍♂️ 🤦‍♂️

[karmic musk]

and the reason this happened is that I built the crate in the same directory of my .cargo/config.toml 🤦‍♂️🤦‍♂️ 🤦‍♂️

[limber wedge]

Hahaha happens. I think maybe a —v flag for extra verbosity could be useful for these cases where we also print the complete config so its easier to compare

But glad it works now!

[rocky oxide]

cc @vast vine lol

We've discussed this before here

[vast vine]

Yeah, I'm not surprised lol. It was easier than I expected to get that prototype working. It's more general purpose than bevy though so I was planning on keeping this standalone

[limber wedge]

Ye we support this already: https://thebevyflock.github.io/bevy_cli/cli/examples.html

[vast vine]

ah TIL

[karmic musk]

Hi, can anyone take a look at this PR: https://github.com/TheBevyFlock/bevy_cli/pull/650
I believe it should be ready for merge.

[foggy basin]

Merged!

[karmic musk]

Thank you!

[halcyon saddle]

Just wanted to drop a note -- thanks for this tooling! It makes webgpu testing a lot easier!

[opaque anvil]

Are there any plans to integrate subsecond into bevy_cli?

[rocky oxide]

That's the hope, but I don't know what the progress is on that

[foggy basin]

We have an issue for it, but no progress so far. Back then it was put on hold.
https://github.com/TheBevyFlock/bevy_cli/issues/451#issuecomment-2932348363
I assume it's something for post-upstreaming

[opaque anvil]

it's something for post-upstreaming
Is there something that needs to be done on Bevy's side? AFAIK, hotpatching already works ootb, but you need to use dx instead of bevy_cli

[foggy basin]

I think it's more about integrating it into the existing toolset rather than enabling the functionality itself.
So that you can use one CLI tool with a unified interface for all common task, instead of switching between different tools.
I expect the integration will just be a wrapper around either subsecond directly or dx

[twilit dew]

Wizards, can you fact check this?

And this

I bet one of you has lurked deep enough in the compiler to know :p

[limber wedge]

well you can yea but im not sure if you will have fun doing this

[earnest gate]

don't think member order is a breaking change

[quick kayak]

@pale viper i think there's a good chance https://github.com/rust-lang/rfcs/pull/3808 merges in the next couple weeks - interested in working on the implementation?

most of it already exists, there's just a few small things about name res that need to change

[civic dirge]

multiline inline tables seem to break the bevy cli they work fine with cargo now though

> bevy run web --verbose
debug: running: `cargo metadata --format-version 1`
debug: using defaults from bevy_cli config:
       features = ["dev"]
       default-features = false
       headers = []
       rustflags = [
           "-Zshare-generics=y",
           "-Zthreads=8",
       ]
error: failed to parse workspace manifest

Caused by:
    TOML parse error at line 2, column 9
      |
    2 | bevy = {
      |         ^
    newlines are unsupported in inline tables, expected nothing

[foggy basin]

I think that's a feature that has been newly added to toml.
We probably need to update our toml library to support it

[civic dirge]

yeah it is

[foggy basin]

Can you create an issue for it?

[civic dirge]

sure gimme a sec

done, #815

[rocky oxide]

Please take a look at https://github.com/rust-lang/rfcs/pull/3965

I think that this loosening of restrictions would be useful for assorted features of the bevy_cli in the future, and may allow us to operate purely on stable Rust toolchains?

I'm not 100% clued into the exact details of this subsystem though, so I would appreciate your expertise here

[foggy basin]

Hmm not sure yet if this also enables stuff like rebuilding std, which we need for the wasm stuff. Definitely worth an investigation though, sounds promising!

[limber wedge]

I think it only enables easier use of unstable tooling flags not language features. Iirc for multithreaded we only pass linker args and you dont need unstable for passing linker args in general but you do need it for the once we pass and that would not change with that rfc?

[foggy basin]

Not entirely sure. The usecase description definitely sounds like our usecase so I hope it will work for us

[limber wedge]

i think this should be fixed on main

[civic dirge]

oh my bad then

[pale viper]

Hi! Congrats on the FCP, that's awesome! I don't think I have time right now to work on the implementation, as much as I'd love to. I'm participating in Google Summer of Code, which is consuming most of my coding free time

Thanks for reaching out, though!

(Also hi everybody, I'm so sorry for being absent for so long! I hope you all are having a good summer :)

[foggy basin]

https://blog.rust-lang.org/2026/05/28/Rust-1.96.0/

WebAssembly targets no longer pass --allow-undefined to the linker which means that undefined symbols when linking are now a linker error instead of being converted to WebAssembly imports from the "env" module. This change prevents modules from linking unless all linking-related symbols are defined to catch bugs earlier and prevent accidental issues with symbol naming or similar.

Wow I remember hitting this case, it was very annoying to debug. Good change

[tardy cove]

is there any way to specify the version of wasm-bindgen cli to use? Nix only has up to 0.2.114 but bevy cli is asking for 0.2.122

[foggy basin]

No. The wasm-bindgen version is tied to the exact version that's used in Bevy. Wasm-bindgen requires an exact match or will throw an error

So your only option is probably to use an older version of Bevy that uses the wasm-bindgen version you need