bevy_cli

[limber wedge]

But i agree we have a lot of cool new features!

[pale viper]

Is there anything else you think is missing? Any features or bugs we should get in before releasing?

[limber wedge]

I think: https://github.com/TheBevyFlock/bevy_cli/issues/488 would be good the rest we can cut imo

[twilit dew]

Wait, you guys are not using main?

[sturdy tapir]

any of yall have good resources for rustc driver making? seems like everything is just the rust dev info or drivers for kernels not rustc

[limber wedge]

i liked this one from jyn https://jyn.dev/rustc-driver/ as an easy entry point

Otherwise the rustc compiler guide is good too: https://rustc-dev-guide.rust-lang.org/

[twilit dew]

Can someone here help @opaque wren ?

#1409029349344284672 message

[sturdy tapir]

"easy entry point"
looks inside: "So clippy is actually 8 processes in a trench coat, and does file path magic"
Yep knew this wouldnt be easy but oh boy i got alot to learn

[sturdy tapir]

Ok this is hurting my head
they seem to leave some stuff out cause i cant replicate a working setup from their code.
rust analyzer is freaking out over toolchain stuff

[rocky oxide]

jyn is great 😄 They're very nice!

But also yeah, the rustc devs tolerate a shocking amount of bullshit from their tooling

[sturdy tapir]

yea and from search jyn's is the only actual attempt at a driver walkthrough, or im just drowning in kernel driver results
like rn rust analyzer is freaking out over cargo-clippy not being for the toolchain, yet nothing on what im supposed to do and no mention of this in jyns article makes me question if i did things right to begin with

even the rust-dev guide doesnt clearly layout the environment needed fully

with how important these drivers are to the ecosystem i wouldve imagines a tiny bit more from people about them

[rocky oxide]

A lot of people have a similar experience to you

Where they go "oh hey that sounds neat!" and then promptly drown in arcane setup

[sturdy tapir]

this is the exact problem that drove me away from learning C/C++ was the billion line make files and weird special setups

[rocky oxide]

Yep, me too 😄

But yeah, this is why my pushback was so strong. It wasn't that your arguments were bad: it was just that you were underestimating the level of nonsense

[sturdy tapir]

im sure someone experinced wouldnt have much issue, its just the materials to get from "regular rust dev" to "can start learning rustc driver stuff" is practically non existent

[rocky oxide]

lol, talking to jyn has convinced me that this is very much not a skill issue

FYI @quick kayak

[quick kayak]

(acquiring context)

[sturdy tapir]

i dont mean skill issue, more "has already internalized the prerequisite knowledge"

[quick kayak]

everything is a mess because no one in the project talks to each other

[sturdy tapir]

wanting to solve bevy editor issues by making a rustc driver that dumps needed reflection data to a txt file for the editor to parse

[quick kayak]

there is a much simpler world possible but it requires people actually designing things instead of heaping more complexity on top

[quick kayak]

you are in for a world of hurt 😓

what "reflection data" do you need?

[quick kayak]

what errors are you running into?

fwiw i never actually tested the rust-analyzer stuff lol

[quick kayak]

yeah things are fucked lol

most people working on rustc don't have to think about it because x.py makes things nice

but when you work on your own driver you don't have that

[sturdy tapir]

the scene notation cart is building allows for a component to not have all data feilds listed, but the editor needs to know all possible feilds, so we need a secondary source to tell the editor anything thats missing.
Reflection is a option, but requires a working game to request data over bevy remote protocol
to circumvent this i want to dump the reflection data into a text file, circumventing need for a full working compile of the game project

[quick kayak]

"all possible fields" where are they coming from? a trait the component is implementing?

also when you say "scene notation" is this a macro or a tool that generates rust source code?

[sturdy tapir]

the component itself,

aka
a bsn file could look like

   A: i32
}```

but the component in the code is 
```component {
   A: i32
   B: i32
   C: i32
}```

the editor needs to know about B and C but cant at the moment

[quick kayak]

my question is where B and C come from

[sturdy tapir]

asset file and macro, but editor only concerned about the asset file

[rocky oxide]

They're just ordinary fields on a struct

[rocky oxide]

.ron analogue 🙂

[quick kayak]

i'm still confused. component is a pre-existing struct? what is the BSN file declaring?

[sturdy tapir]

2025-08-24T21:15:27.952767307-04:00 ERROR Flycheck failed to run the following command: CommandHandle { program: "/home/rin/.cargo/bin/cargo", arguments: ["clippy", "--workspace", "--message-format=json-diagnostic-rendered-ansi", "--manifest-path", "/home/rin/Documents/RustDev/bevy/Bevy_rustc_driver/bevy_rustc/Cargo.toml", "--keep-going", "--all-targets"], current_dir: Some("/home/rin/Documents/RustDev/bevy/Bevy_rustc_driver/bevy_rustc") }, error=Cargo watcher failed, the command produced no valid metadata (exit code: ExitStatus(unix_wait_status(256))):
error: 'cargo-clippy' is not installed for the custom toolchain '/home/rin/.rustup/toolchains/nightly-2025-08-07-x86_64-unknown-linux-gnu'.
note: this is a custom toolchain, which cannot use `rustup component add`
help: if you built this toolchain from source, and used `rustup toolchain link`, then you may be able to build the component with `x.py` 

[quick kayak]

turn off clippy for any custom rustc driver

use rustc instead

clippy is even more fucked than a normal rustc driver

[rocky oxide]

The BSN file declares values for instances of a pre-existing type. Not all fields must be listed, nor do we have full type information. Instead, when the scene file is loaded into the user's game, missing values are defaulted and you do serde style parsing and type coercion

Notably, BSN files do not have type definitions in them: those live in the the user's game

[quick kayak]

ohhh i see, you have some code that's going fn load_from_bsn(file) { Component { A: 1, ..Component::default() }

and you want to know what's in default()

[rocky oxide]

But we would like to be able to read these files from a different binary (the editor), and it would be nice if the user's game didn't need to be running or compiled in order to get that information to the editor

[quick kayak]

yes

[sturdy tapir]

alright gotta go check how cause only do single lints disables before

[quick kayak]

this is hard and i understand why you wanted a custom rustc driver

[rocky oxide]

My stance right now is a) "I agree that this would be nice" and b) "boy this is going to suck, we should probably just relax that requirement"

But I am open to being proven wrong!

[sturdy tapir]

yea, i thought of combined compilation as another method but its really sketchy
rustc or static analysis has been only other ideas

[quick kayak]

ok so two thoughts:

1. rustc is not really robust to broken code and rust-analyzer is
2. LSP protocol is much much easier to work with than a rustc-driver

have you considered asking RA for this info?

[rocky oxide]

Right, using an LSP is a reasonable idea for this 🤔

[sturdy tapir]

Did not know that was even an option, do you mean we could piggy back off rust analyzer for this info?

[rocky oxide]

1 is a particularly strong point

[quick kayak]

yes; they probably don't have an LSP query with exactly what you want but i suspect it's easy to build RA as a library

certainly easier than rustc

[sturdy tapir]

yea, tho i was under impression rustc had full ast access
nothing has implied it wasnt robust enough

[quick kayak]

it really depends which part of compilation is broken, it has abort_if_errors() all over the place

[rocky oxide]

Yeah, but it's not intended to work for half-broken code at all. It just gives up

[quick kayak]

RA doesn't do anything like that

[sturdy tapir]

Ill have to look at that for sure then

[sturdy tapir]

ahhhh

[rocky oxide]

Thank you @quick kayak ❤️ Really appreciate you offering your guidance here

[quick kayak]

<3

[sturdy tapir]

Yea!

[quick kayak]

anything that works pre-borrowck is going to be easier with RA IMO

[sturdy tapir]

I didnt even know we had someone with this knowledge here

[quick kayak]

i would only use rustc-driver if you need to codegen or emit .rmeta

[rocky oxide]

My job is to know people 😄

[quick kayak]

i would like rustc-driver to be good for dataflow analysis but i don't think it is today, rustc is too monolithic

[sturdy tapir]

nice, we dont necessarily need codegen atm unless we expand some editor scope

[rocky oxide]

I remember Niko complaining to me about this like 5 years ago on a call lol

[quick kayak]

lol yeah

it's still bad

stable-mir is working the wrong way around IMO

they need to make the code a library and then commit to a stable API

[sturdy tapir]

i imagine rustc is plagued with tech debt so makes sense

[quick kayak]

the current approach is signing up for a world of hurt

[quick kayak]

honestly "tech debt" is not the problem so much as lack of experts

and the way that rustc rewrites literally everything from scratch because it existed before crates.io

[sturdy tapir]

that was another concern i had was looking in the deps tree for 3rd party plugins the user is using

[rocky oxide]

cargo-manifest exists at least, and I don't expect that the other information will be super hard to get

It all gets compiled into the same thing, regardless of the source

And Rust doesn't use binary blobs in a way that will cause you problems ||unless you're dtolnay||: you'll always have the source code available

[quick kayak]

god i still remember Alexis King asking 5 years ago "why is proc-macro2 not Simply part of std" and i had to explain to her exactly how proc-macro's ABI is fucked lmao

i'm really glad i no longer work on rustc tbh

[rocky oxide]

You seem happier!

[quick kayak]

i am happier :)

[quick kayak]

also explaining channels was a whole thing, i think that was the first time i realized that other places just Don't Do This

[sturdy tapir]

we might have to cross that bridge when we get to console support i fear
not gonna be fun

i know at least nintendo would be the kind to say "screw you make it work"

[rocky oxide]

Yeah, you would run into problems trying to edit objects defined in other languages in general, but you'll need a mirror type or at least a dynamic component type so uh we should be fine

[pale viper]

This comment really made me think about how we're currently building the CLI

Right now some of the CLI's code API is technically public, through the commands module

You can technically add the CLI as a dependency and use that instead of spawning process

But even still, the experience isn't amazing. We make interactive prompts when you use the library unless you manually pass --yet

I kind of want to do what cargo-binstall does, which has binstalk as the main library interface with all the CLI niceties ripped out

[rocky oxide]

Yes: I really like that sort of division

[pale viper]

It gives more control to those using the CLI as a library, and reduces compile time since we're excluding stuff that's not needed

[quick kayak]

cargo is in this situation and it's really painful

it's kinda the same situation as rustc-driver except there's no RA alternative for cargo

[pale viper]

Last I remember, the editor wanted to depend on the CLI in some form to do some heavy lifting with the project management
If we separate the binary and library into two crates, that should make the editor devs' lives much nicer

[quick kayak]

how stateful is your CLI?

[sturdy tapir]

that would be nice for the editor

[pale viper]

Not very! It doesn't retain any state across multiple executions

[quick kayak]

"multiple executions" so within the process it's stateful? that will make things painful for the editor devs

rustc has something called a Session and it caused RLS so much trouble

[sturdy tapir]

yeaaaa

[pale viper]

Is Session stored in a static? AFAIK, we don't use statics at all

[quick kayak]

that's kinda not my point idk

[pale viper]

Then I'm not sure I understand, sorry!

[quick kayak]

if your CLI interface is fn build_bevy_project(Session), is it safe to call that multiple times with the same session? with different sessions? what if the bevy code you're building is broken or Session gets into a bad state?

[pale viper]

Ohhh, I see

I'm not positive on this, but I believe we don't have anything like that

Even for things like configuration loading, we do it each time you run bevy build or bevy run

[pale viper]

When we potentially redesign the CLI's library interface, what things should we look out for like this? Any tips?

[quick kayak]

basically an editor turns a pure function (code -> compiled code) into an operations concern

so you need to think about things from an operations perspective

[quick kayak]

be very cautious about mutating state that persists between calls to the function, either &mut args or global statics

inspect your error handling code; catch_unwind is fine but it can't handle process::exit

either change all your functions to return Result or think about unwind safety

[rocky oxide]

Moar Result!

[quick kayak]

yeah Result is low hanging fruit

your dependencies are going to panic though and you need to handle it when they do

[pale viper]

Good news is: we almost exclusively use Result! It's propagated all the way to fn main()

Thanks for the advice! It'll definitely be useful in the future :)

[quick kayak]

i think those are the big ones. make sure that any disks writes you do are atomic

if you panic halfway through compiling, you don't want to leave around broken code

[pale viper]

We wrap cargo for compilation operations, so if they do it we should be fine

[quick kayak]

i have bad news https://github.com/rust-lang/rust/issues/81280

if you don't cancel cargo while it's running you'll hit this "no more often than a normal project"

[pale viper]

Some of our other external CLIs may also be an issue: we use Rustup, wasm-bindgen, and wasm-opt

[quick kayak]

but this issue makes debouncing + resumption hard

[quick kayak]

rustup is NOT concurrent safe

https://github.com/rust-lang/rustup/issues/988

[pale viper]

Ok, then we'll want some sort of file lock that prevents multiple Bevy CLI instances from using Rustup to install things

I think the standard library recently stabilized an API that should help with that

[quick kayak]

locking is its own whole mess but that sounds like basically the right approach yes

oh interesting

[pale viper]

https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.lock

[quick kayak]

neat

[pale viper]

The API looks very similar to non-Rust mutexes, where you need to remember to call mutex.lock() before accessing a separate variable

We may want to make a wrapper that uses Drop for that, like Rust's Mutex<T> struct

[quick kayak]

that sounds smart

[pale viper]

Either way, thanks for the convo! I'm headed to sleep now, my first day of classes starts tomorrow :)

[quick kayak]

good luck have fun!

[limber wedge]

I think we should tackle these things after a new alpha release. Just some general cleanups and api improvements

[opaque wren]

Should I move my issues here?

[limber wedge]

We sadly cant make threads in here

[foggy basin]

Yea we don't have any persistent state or caching etc yet.
Right now the CLI boils down to calling cargo metadata and then executing other CLI tools with the right set of arguments

[limber wedge]

Do we want to include this: https://github.com/TheBevyFlock/bevy_cli/issues/476 in alpha-0.2.0 or rather include it in a general refactoring/ polishing for alpha-0.3.0?

[foggy basin]

I wouldn't block the release on this, personally

[limber wedge]

I agree i think it fits better with a refactoring/ cleanup 0.3.0

[pale viper]

Yup, I wouldn’t block either. It could be a lot of effort, and is too risky to release immediately imo

[rocky oxide]

FYI, something I'm going to want out of this tool in the future is the ability to easily prepare (and ideally share) game builds, editor builds, or game w/ embedded editor builds

Not MVP scope or anything, but I want to make sure it's in the back of your minds

[limber wedge]

I would like to put this into the 0.2.0 milestone: https://github.com/TheBevyFlock/bevy_cli/pull/553. But imo we can cut: https://github.com/TheBevyFlock/bevy_cli/issues/418 and https://github.com/TheBevyFlock/bevy_cli/issues/488. I think https://github.com/TheBevyFlock/bevy_cli/issues/488 could get fixed automatically when we refactor our config parsing etc.

Would rather then start a release for alpha-0.2.0 and then perhaps start with switching to figment so we get a feeling how this could look

[foggy basin]

Sounds good to me 👍

[pale viper]

Agreed! Feel free to update the milestone as you described!

I’m planning on doing some review work tomorrow, so hopefully we can get some PRs merged by the end of the weekend

[foggy basin]

Tomorrow I should have time to address the feedback on the getrandom PR :)

[foggy basin]

Hmmm, if I understand correctly, --config is more limited than Cargo.toml and I can't use package aliases. So I can't configure multiple versions of getrandom separately, which would make it impossible to add both the js feature for v0.2 and the wasm_js feature for v0.3... annyoing

In fact (at least if ChatGPT doesn't lie), it seems that it's only possible to configure dependencies this way if they are already configured in the Cargo.toml directly 🤔

[foggy basin]

So we might only be able to apply the rustflags fix directly.
We could check if we could automatically enable the web feature flag for bevy, which (I would hope) also enables the corresponding getrandom features.
Or we need to fall back to an error message, giving the user the text to paste into Cargo.toml

[pale viper]

Is this because —config overrides values from .cargo/config.toml instead of Cargo.toml?

[sour cypress]

I was setting up a new machine and wanted to install the CLI so I followed the readme and did:

cargo install --git https://github.com/TheBevyFlock/bevy_cli --tag cli-v0.1.0-alpha.1 --locked bevy_cli

However that results in the following error for me:

error: could not find `bevy_cli` in https://github.com/TheBevyFlock/bevy_cli?tag=cli-v0.1.0-alpha.1 with version `*`

Installing with the specific commit hash like:

cargo install --git https://github.com/TheBevyFlock/bevy_cli --rev 2d12bc0eff065e2064f2f75809e819e25852fcc3 --locked bevy_cli

Seems to have worked as I would expect though I haven't tested any cli commands yet.

[limber wedge]

I think you are just not allowed to specify optional dependencies via cli that are not part of your lockfile

[limber wedge]

Hm interesting maybe there was some connection problem? Does it still not work?

[sour cypress]

I tried that command at least 3 times before I went the revision route and got the same error every time but I just tried uninstalling and reinstalling and this time the command worked without error. I guess it was indeed something like a connection problem... 🤔

[foggy basin]

If I undstand correctly, it just has different semantics than merging.
We would need to verify again, but apparently you can only modify dependencies that are already defined in your Cargo.toml

[limber wedge]

Since bevy 0.17 already includes that feature for the web i think its fine if we just print what the user should add to their Cargo.toml in case its not defined.

[limber wedge]

hows college so far? @pale viper

[quaint pollen]

quick question here. is it possible for bevy run web to support building with webgpu target? I saw the args forward pull request but the following command doesn't seem to work...

bevy --verbose run web --open -- --api webgpu

[twilit dew]

yes, you want bevy run --features bevy/webgpu web

activating webgpu is nothing "fancy", it's just a feature you need to activate on Bevy's side 🙂

You can also configure your Cargo.toml so that it automatically uses that feature on web calls

Maybe that should be in the README, quite a few people have asked this already, so it's worth pointing out!

[quaint pollen]

Thank you!

[pale viper]

It's been going really well! I've met some really nice friends, and the classes aren't too difficult yet

I have a little server running Jellyfin that I've been trying to setup with my dorm's TV so my friends can watch shows and movies together :)

I'm joining the college game design club, hoping to share Bevy with some other people in that scene!

[limber wedge]

Aww glad to hear! 💙

[foggy basin]

Alright, what do we think about this output when the getrandom features are not configured?
The RUSTFLAGS are still applied automatically

The CLI tries to find the minimal fix:
It only suggests the features for the versions you are actually using and only uses the more complex package syntax when you are actually using multiple getrandom packages

Also need guidance on what to do when we encounter get random versions beyond 0.3:

1. Assume nothing needs to be done
2. Assume they need the same fixes as 0.3

Currently have a tendency to do (1), as suggesting nothing is probably better than suggesting a wrong fix

[limber wedge]

I would say (1) wrong suggestions are really annoying

[limber wedge]

I like the help message but i think it should be an error level?

[foggy basin]

Hmm yea, I wasn't sure which level to choose. I can switch it :)

[pale viper]

If possible, I would try to make the actual TOML code snippet a little more clear (I didn't see that it was part of the warning message at first)

You could indent it to align with the rest of the message, maybe add some ANSI escape code colors?

We basically want that message to be the brightest thing on the screen, the things that users look at first when they see the compilation has failed

[foggy basin]

We could, but then we probably also have to add checks whether the terminal supports colors and stuff like that

[rocky oxide]

Boy do I want more linting in the repo

[limber wedge]

i would prob start with: https://github.com/TheBevyFlock/bevy_cli/issues/432 after moving but if you have other more important lint ideas let me know!

[rocky oxide]

This is a good idea 🙂

[pale viper]

My plan is to upgrade the linter to support the first 0.17 release candidate, then introduce the linter to the engine's CI

This should make the process smoother, but it does mean we have to wait a little bit longer :)

[foggy basin]

https://tenor.com/view/sweats-gif-25346666

When you have two more days to set up your website and host a blog post on it...

[twilit dew]

I use https://bearblog.dev

Can recommend 🙂

[foggy basin]

I already started setting up a page with Svelte for my RustWeek post (that I never finished 😅), because at some point I want to make the posts more interactive.
(Also I want an excuse to work with Svelte again!)

But when you're low on time, using a custom solution definitely has its downsides lol

[limber wedge]

imagine how much more interactive it will be when you hosted it

[pale viper]

I’m feeling a little bit of this too lol

I have the start of a post drafted, but I really want to finish it today

@foggy basin what are you planning on covering in your post?

[foggy basin]

Only the web stuff. Why it's needed, what it currently does, where we want to go
But I barely started with the writing yet 😅

[foggy basin]

FYI @twilit dew @plush spade the getrandom handling is merged to Main now :)
We had to cut automatically applying the feature, but at least the env variable is set automatically now

[twilit dew]

yayyy!!!

Charlotte can you give the Bevy CLI alpha another try?

I think you'll find it very useful for testing web 🙂

[foggy basin]

Let us know if you run into any unexpected roadblocks :)

(Or even expected ones, maybe we can remove those as well!)

[twilit dew]

Reminder: running an example is bevy run --example foo web, using webgpu it's bevy run --example foo --features webgpu web

[foggy basin]

(I think the foo is missing in the second one)

[twilit dew]

thanks, fixed 🙂

[pale viper]

Cool! I look forward to reading it, even if you don't finish it by tomorrow :)

[pale viper]

We should consider preparing for a release within the next 2 weeks. I think it's super valuable to publish what we have now, so it gets into the hands of users

I consider it a sign to publish when @twilit dew starts using the main branch of the CLI instead of the latest release 😆

[foggy basin]

And after that, maybe we should start focusing on upstreaming
I anticipate it will be a long process and adding new features probably makes it harder

[twilit dew]

I use the main branch since the wasm multithreading updates 🙂

It’s the difference between usable and unusable audio for me haha

[foggy basin]

It will be an exciting day when bevy_seedling is upstreamed :)

[pale viper]

And here it is!

[limber wedge]

working on https://github.com/TheBevyFlock/bevy_cli/pull/574 and thought should unit structs that implement component also implement Clone?

[rocky oxide]

Yes, probably

[pale viper]

Honestly, they may also benefit from deriving Copy too

Is there any scenario where someone wouldn't want a ZST component to be copy-able?

[twilit dew]

When it's also #[non_exhaustive]

[rocky oxide]

When they don't want to pay for extra codegen :p

[pale viper]

I'm not sure I understand, doesn't that only work on enums?

[limber wedge]

No also applicable to structs https://doc.rust-lang.org/reference/attributes/type_system.html#the-non_exhaustive-attribute

[twilit dew]

nope, you can use it to future-proof structs too 🙂

It's just very annoying because for some inexplicable reason, the ..default() syntax does not work with it

But you can also use it to make sure consumers cannot construct a type

For example, subsecond uses one (because of me huehue) to make sure consumers cannot build a funky pointer to a vtable manually. They always have to request such a pointer from the library

[pale viper]

Huh, TIL!

Another thing is that Copy and Drop are incompatible, so that's something else to think about

[pale viper]

Here's a small docs change that replaces our references of https://bevyengine.org to https://bevy.org: https://github.com/TheBevyFlock/bevy_cli/pull/576

I'm working on updating the changelog for the CLI, and should have it finished by the end of today :)

[limber wedge]

@pale viper I started the update to 0.17 https://github.com/TheBevyFlock/bevy_cli/pull/577 feel free to help with the pr 🙂 i try to fix one lint per commit now so its easy to review

[pale viper]

Thank you! I'll take a look at what you've done and try to help where I can :)

[jovial quartz]

does bevy cli main work with 0.17 if you ignore the linting changes? or no

[foggy basin]

Yes it should!
Except for the linter we don't assume any specific Bevy version

[jovial quartz]

cool and thanks

[foggy basin]

If you run into any issues, please let us know. That would be a bug

[jovial quartz]

Everything does seem fine but ill probably wait for the templates to update as manully updating dependcies is spooky

[twilit dew]

Is there any way to tell the CLI that I always want to pass -U multi-threading for all projects? i.e. without adding that to a singular Cargo.toml

The reason is that I setup my global ~/.cargo/config.toml to use the multi-threaded setup (since I have no reason to not use it everywhere)

But that means that I now also need to pass -U multi-threading everywhere or I get issues because of the cross origin policies

[foggy basin]

We do not have any user-wide configuration yet unfortunately

But it would probably be easy to add!

[twilit dew]

Heads-up: I'm updating the bevy_new_2d template to 0.17 right now and will tell people in the readme to use bevy_cli's main branch

The reason is that otherwise, I would have to explain what the heck a RUSTFLAGS is and where to configure it and how it is non-incremental and how you can destroy your config and bla

(because of the whole getrandom bs)

So uuuuh

you may want to publish a release soon 😄

[pale viper]

I opened https://github.com/TheBevyFlock/bevy_cli/pull/581, which updates our changelog with all changes since the first release!

I originally planned on including the changelog updates with the actual release PR, but I think we need to give writing pass over our docs and fix https://github.com/TheBevyFlock/bevy_cli/issues/578 and https://github.com/TheBevyFlock/bevy_cli/issues/580 first

But, since we might see some more users installing main due to bevy_new_2d, I figured getting the changelog published couldn't hurt :)

[limber wedge]

Yea i thought it makes sense to prompt in #580 since the install command is not intended for ci use but you are right its an awkward behavior when the „skip all prompts flag is passed“😂

[twilit dew]

Could bevy new support git tags?

[twilit dew]

Oh nvm it's already an issue https://github.com/TheBevyFlock/bevy_cli/issues/372

[foggy basin]

I was wondering if we should switch from using cargo generate as a library to using it as command
That would make it easier to support all the options it offers

[limber wedge]

I like that you dont have to also download another cli application but i think i should have time tomorrow to open a PR so we could include this in the new release

[sturdy tapir]

@pale viper I remember you wanted to improve the libary side api of the cli, how usable would you say it is rn?

[pale viper]

🙏 Please

cargo-generate is such a heavy library dependency, and the way it defines its dependencies can cause dependency conflicts

I do think the new user onboarding experience gets a little more challenging when bevy new prompts you to install a separate command, but I think it's worth it from a compile time and feature POV

[pale viper]

Right now the Rust API is near identical to the CLI API, check out the Rustdoc at https://thebevyflock.github.io/bevy_cli/api/bevy_cli/index.html

[foggy basin]

If you're missing anything from the public API, feel free to open issues / PRs :)

[sturdy tapir]

im asking for my pert graph

[pale viper]

If you wanted to use bevy run in the Rust API, you'd do something like this:

use bevy_cli::commands::run::{run, RunArgs};

let mut args = RunArgs::default();
run(&mut args).unwrap();

I think the API could certainly be improved, but it works in this form. Treat the Rust API as if the CLI were bundled into your program, and instead of spawning Commands you're running functions

[sturdy tapir]

mmmn i see

[vague brook]

hello ! how to pass multiples args to wasm-opt using the cli ?

Unknown option '-Oz --enable-bulk-memory --enable-nontrapping-float-to-int --enable-mutable-globals'
warning: failed to run wasm-opt, trying to find automatic fix...
error: command `wasm-opt --output /home/mirsella/dev/waykeepers/target/wasm32-unknown-unknown/web-release/game_client_bg.wasm /home/mirsella/dev/waykeepers/target/wasm32-unknown-unknown/web-release/game_client_bg.wasm -Oz --enable-bulk-memory --enable-nontrapping-float-to-int --enable-mutable-globals` exited with status code exit status: 1

i call with bevy build web --wasm-opt "-Oz --enable-bulk-memory --enable-nontrapping-float-to-int --enable-mutable-globals" with the quotes i think its passed as a single arg to wasm-opt.
ive just put the args in my cargo.toml in the meantime :)

[foggy basin]

Try passing them separately, I.e. --wasm-opt=-Oz --wasm-opt=--enable-bulk-memory etc.
It might also work to separate them by commas, although I think that's OS-dependant

[limber wedge]

https://github.com/TheBevyFlock/bevy_cli/pull/597

[crude mica]

I am somewhat interested in trying to roll in the features of cargo apk into bevy cli

Cargo-apk uses ndk build it doesn't do that much itself, so we can use the same library it does, it seems like something we can roll in, thoughts?

[pale viper]

I think that would be very interesting. We already provide extended support for web, but I'd like to see better support for VR, iOS, Android, etc.

Like bevy build android

[pale viper]

That's actually crazy

[foggy basin]

That will be nice for CI install times

[pale viper]

The PR reduces build times from 47 seconds to 14 seconds

While users will still have to pay for that compile time when running bevy new for the first time, this drastically reduces the cost of upgrading to new versions and using the CLI in CI

[limber wedge]

Yes i think this would be the end goal. I think ideally we would try to not include new commands for the next release (after the current one) and focus more on improving the current set and work towards upstreaming.

main point for me would be:

1. introducing a cli config file that can be used to configure settings that should be used across projects

2. look into refactoring config parsing / resolving

3. better infrastructure to support wrapping other clis (for example give clear credit, always support forwarding args, handle minimal required versions -> automated update if the version is too old)

4. some documentation ci / checker so we dont forget config options

[pale viper]

I think that's a good roadmap, I'd also like to add better testing to the list

I've been investigating how Cargo does integration and UI testing, and I think it's a really good place to start from

All post-release stuff tho :)

[limber wedge]

Yes!

[pale viper]

Ok, I just finished a review of the cargo-generate PR. There's some changes I'd like, and a panic that happens when you run bevy new --help

Let me know your thoughts :)

[pale viper]

I also re-reviewed your bevy lint --yes PR. Unfortunately the whole Version sorting business led to a breaking change with the v version prefix, so I left a comment about that

[twilit dew]

But that would mean I have to create my own meshlets and abandon my hopes that y'all would figure that out for me /j

[foggy basin]

Handle minimal required versions -> automated update
We support that already I think! I think we allow a VersionReq to be passed instead of just a plain Version and that can also be a minimum requirement

[foggy basin]

Or you just wait like... 2 years until the upstreaming is complete and we implemented it on the upstream CLI

[pale viper]

I actually think we could get it upstreamed by the end of this year

[foggy basin]

I'm very curious to see how the upstream process will be :)

[pale viper]

There’s a few road bumps we may run into, but I’ve been thinking about this for a few months now, and I think I have a good idea of how it will go

Once the new CLI version is published, I think upstreaming is what I want to work on next

[limber wedge]

yea we do but we dont use it in all instances

[crude mica]

Hmm so an ability to build for android being integrated into bevy_cli is not currently desired?

@pale viper @limber wedge ?

[foggy basin]

I would say it's desired, it's more a question of prioritization in my eyes.
The more features we add to the CLI right now, the longer the upstreaming process will take when it happens.
And since it's open source, it's probably not so clear cut, because also the resources we have available can change (e.g. you contributing the feature).
So it might be more of a question if you are willing to also invest the energy to upstream the feature after you have implemented it in the prototype :)
(at least that's my perspective, not sure what the others think)

[pale viper]

My thoughts exactly. We want Android support, but we’re not going to work on it yet

[crude mica]

But i can work on it

Okie

Yeah I didn't expect yall to be the ones working on it

[rocky oxide]

I am very interested in making mobile builds easier and better documented

[foggy basin]

I don't have any problems with that personally :)
Just be aware that features that are accepted in the prototype are not guaranteed to be upstreamed, so there is always the risk of some work to be wasted (both regarding the what is accepted and the how it's implemented)

[pale viper]

Yup, and we’ll gladly support you if you want to work on it!

[foggy basin]

Ultimately, I think an android integration in the CLI will be very beneficial and make the process a lot less frustrating and a lot more accessible to the user. Very similar to the web work we have done

[crude mica]

Yeah, I wanna make the process of building for quest a lot easier and less confusing

[pale viper]

Definitely open an issue if there isn’t one already. We can centralize designs and feedback there ;)

[crude mica]

Yeah, I have to think a bit further on what would be optimal but i'll probably do something tonight

[foggy basin]

Yea, writing down a design draft first is probably a good idea. You could also try to get a maintainer review it, to ensure at least the general direction is fine. Also getting feedback by other android devs would be good :)

[pale viper]

@foggy basin with the unstable WASM multi-threading you implemented, is it possible to configure the scheduler to be multi-threaded?

I know it says that Bevy doesn't take advantage of multi-threading on web when it's enabled, but is there a way to force it to?

@shrewd monolith you may know as well :)

[foggy basin]

The Bevy task scheduler? No, it doesn't change anything about the app by itself. AFAIK its not possible yet
With @snow linden's rework of the whole task stuff it might be possible, but from what I know the current implementation doesn't support it

[shrewd monolith]

Yeah it's still a bit difficult to abstract over even if it can technically be done.

[snow linden]

Experimental support should come in the next few versions

[pale viper]

Ok, good to know! Thank you :)

I'm working on sprucing up the CLI's docs before we release, and I'm on the web multi-threading page right now

[rocky oxide]

Honestly if we can get this + WebGPU web is looking dramatically better. Memory shrinkage would also be good

[foggy basin]

Extending the web docs is also on my todo list (or rather, wishlist).
Unfortunately I barely have time and energy as of late.
(still have to finish my birthday blog post 😅)

Thanks for working on this!

[pale viper]

Yeah, no problem! I've been struggling with finding the energy too recently, but today's been a good day :)

(still have to finish my birthday blog post 😅)
If / when you finish it, I'd be happy to give an edit pass

[foggy basin]

Agreed, the future of web apps is looking bright! Or, at least viable :D
Lots of exciting stuff in the works!

[pale viper]

Does Firefox support WebGPU yet? I'm juggling both Firefox and ungoogled-chrome right now, but I prefer Firefox for dev stuff

[dusky onyx]

Web apps are already viable, bevy is at the heart of my company's web platform. Threading and especially webgpu would make it even better though, I've been waiting for a long time for those 😄

[foggy basin]

I think it does on windows but not yet on linux. At least by default

[dusky onyx]

You need flag(s) on linux yeah, and it probably works better on nightly

[foggy basin]

Fair! Although that's probably more an amazing achievement by you and less the amazing state of the bevy web story at the moment :D

But it really feels like the pieces are starting to come together

[foggy basin]

I can't remember, which parts of Bevy did you use? Rendering and ECS? Or also the UI/text stuff?

[pale viper]

I'm not sure I was around / paying attention for this, how did @dusky onyx help with Bevy's web support?

[dusky onyx]

We use most of it except 3d, previously we didn't use UI but I implemented worldspace UI recently

[rocky oxide]

Nice: I'll need to remember to bother you about worldspace UI when we next take a real crack at it

[foggy basin]

Oh I meant rather that its an accomplishment to build such a poloshed product with the current state of both wasm/web rendering and Bevy web :)

[pale viper]

-# I think that's what I'm missing, what product was it? Was it for a game jam?

[dusky onyx]

It's a CS2 analytics platform, I showed it at rustweek

[foggy basin]

I think its https://skybox.gg/ if I remember correctly

[pale viper]

Oh no way! I think I saw that in one of Bevy's release posts!

[dusky onyx]

lmao our embed is trash

[foggy basin]

Hahaha

WordPress? Interesting :P

[pale viper]

@foggy basin how does this look for a revised intro to web multi-threading?

[rocky oxide]

@dusky onyx are you okay if we list this on bevy_awesome_prod. I don't think @polar geyser has it listed

[dusky onyx]

It's already on!

[foggy basin]

I think you actually need to use firewheel-web-audio and bevy-seedling in combination if memory serves me right, but @shrewd monolith will know the recommended setup :)

I need to head out now, I'll try to look at the changes tomorrow :)

[limber wedge]

thats so cool!

(jobs link is broken)

I think there was an attmend to do something similar for league but it was not from your company?

[shrewd monolith]

That was required previously, but I just went ahead and integrated firewheel-web-audio directly in 0.5 to save a bit of trouble. So indeed, the web_audio feature is basically the only requirement.

[dusky onyx]

Yeah everything is a bit broken, the company went through a big restructure a couple of months ago xD but thanks for letting me know.

There's a bunch of companies doing similar things for other esports games, we're currently only doing CS2.

[vague brook]

hello, how to use [package.metadata.bevy_cli.web] to add wasm-opt args when building with a custom profile ?

• [package.metadata.bevy_cli.web.web] works when using --profile web
• [package.metadata.bevy_cli.web.web-release] doesn't work when using --profile web-release.
  same with [package.metadata.bevy_cli.web] and [package.metadata.bevy_cli.web-release]
  thanks !

[limber wedge]

Not sure I understand you correctly but if you want to build for the web you dont have to pass the profile, the cli will choose the web profile automatically see: https://thebevyflock.github.io/bevy_cli/cli/configuration.html

So i would add the wasm-opt args under package.metadata.bevy_cli.web.release for release settings and package.metadata.bevy_cli.web.dev for dev settings. If you want to use the same settings both in dev and release builds then add then under: package.metadata.bevy_cli.web

[vague brook]

oh i missed this page. thanks ! got confused because of web-release using release and not web-release in the config

[limber wedge]

No worries! The config documentation is also not fully up to date https://github.com/TheBevyFlock/bevy_cli/issues/578

[foggy basin]

The release setting in the config applies to both native and web release builds (when you use --release)
If you want your config to only apply to web release builds than you can use web.release

Maybe its confusing that we use "profile" when distinguishing between dev and release in the documentation, since its not (always) the same as the cargo profile that's used...

[vague brook]

no the doc at https://thebevyflock.github.io/bevy_cli/cli/configuration.html is pretty good !
sadly i just didn't stumble upon it

[pale viper]

Could I please get a review on https://github.com/TheBevyFlock/bevy_cli/pull/598 and https://github.com/TheBevyFlock/bevy_cli/pull/581 ? They're docs and changelog improvements for our upcoming release

(And @limber wedge I'll try to look at your changes later today :)

[limber wedge]

Thank youu and no worries if you dont get to them , reviewing can be rather exhausting 💙

[pale viper]

Ok, I had a good focus block today! #582 and #597 are now merged (with minor changes), and I updated both #581 and #598

I think once both of my PRs are merged, we can finally release v0.1.0-alpha.2! Super exciting :)

We have a lot of really good changes with this release, and I'm hyped to see us actually crossing the finish line

[limber wedge]

Should be able to review them tonight or tomorrow morning thank you so much for finishing my prs

[twilit dew]

how come we don't binstall cargo-generate for users?

Also, uuuh,

I get this when the bevy cli tries to install cargo-generate for me

[limber wedge]

I dont think installing pre built binaries is a good idea maybe one day we could provide a flag in a general config to „use binstall“

[twilit dew]

how is it different from letting the user compile and execute arbitrary code?

In other words, if I don't trust the binaries from their releases, why should I trust the binary I compile myself from their code?

[twilit dew]

running a rustup update, let's see

[limber wedge]

Well its more that you minimize attack vectors. If you install by source you „“only““ have to trust the source

[twilit dew]

works now!

[rotund condor]

tbf i like compiling from source cuz it gives me an excuse to catch a break

[twilit dew]

Fair enough

[twilit dew]

this is true

based and relatable

[rotund condor]

oh yeah, ill be back in 30

[twilit dew]

is there a command to upgrade all installed tools?

[rotund condor]

cargo install-update -a from the cargo-update tool

[twilit dew]

ah, neat!

[rotund condor]

it works directly with binstall btw

so I had to uninstall binstall

i bet it's speed otherwise

[twilit dew]

this is a good tool 👀

thx

[twilit dew]

yeah it took about 6 seconds for everything

Apparently it uses https://github.com/cargo-bins/cargo-quickinstall ?

never heard of that

https://github.com/cargo-bins/cargo-quickinstall/issues/441

Is that good?

lol

[shrewd monolith]

i would say that's not very good

oh this isn't author (but is collaborator?) anyway it doesn't inspire confidence

[twilit dew]

lol

[rotund condor]

weird. i only got insta-installs with binstall installed but since i unininstalled binstall cargo install-update won't install binaries, just compile

[twilit dew]

so uuuh

@limber wedge this experience tells me y'all did the right thing

lol

[twilit dew]

Ooooh that's from cargo-binstall

I think it can use cargo-quickinstall as a source

[limber wedge]

Hahaha i have to read this tomorrow

[foggy basin]

I think we may wait with that until we have user settings for the CLI
We cannot expect it to be installed already, we shouldn't make it required, but it also feels bad to check if its installed on every invocation...
Ofc we can use a feature flag, but most people will install with default features

On the other hand, I guess we would only need to check if binstall is available when we install a new tool, not on every command invocation.
So maybe it's not that bad

[limber wedge]

Yea that issue summs it up really well why you do not want to install pre built binaries for your users (even if it ended up being a false positive)

[pale viper]

This is likely why Cart was against us suggesting cargo-binstall as the primary method to install the CLI

But either way: it was a good thought, but we should definitely hold off until we get user settings

[pale viper]

The Rustup upgrade ended up being much quicker than I expected, so I brushed off my creative writing skills with #600

If only this were Mwiting Monday, it would've been perfect! :)

[pale viper]

<@&1064695155975803020> We in the Bevy CLI working group believe we are prepared to publish the second release of the CLI, v0.1.0-alpha.2! In order to publish, we need at least one approval from a core engine maintainer. If you are interested, please leave a review over at https://github.com/TheBevyFlock/bevy_cli/pull/603. We're super excited with the improvements and fixes made over the past 4 months, and can't wait for others to benefit from them! Thank you

[rocky oxide]

Change log LGTM, but I don't have the time to play with this just yet 🙂

[limber wedge]

The PR that supports Bevy 0.17 is ready now

The observer overhaul changes is most of the diff ^^

[pale viper]

Ok! I’ll try to take a look tomorrow ;)

[sturdy tapir]

wonder if thatll fix issue im having, have version conflicts trying to pull cli in as dependency on launcher

[pale viper]

I don’t think that’ll help, unfortunately, as the PR we were discussing was related to the linter

The CLI is agnostic to what Bevy version you use

[sturdy tapir]

seems im importing wrong then, cli isnt on crates yet so tried the repo

https://github.com/Atlas16A/bevyEditor/blob/editor_foundation/bins/bevy_launcher/Cargo.toml

seems like tempfile and serde_json are multiple conflicting versions in the tree

[limber wedge]

I tried running this branch and it froze my pc

[sturdy tapir]

use cargo run --package bevy_launcher to run it

[limber wedge]

hm it does not start for me

[sturdy tapir]

prob because of the conflicts i was talking about

idk how to resolve these version conflicts

im guessing something in cli needs updating

[limber wedge]

hm but i don't see any? cargo tree -d | grep "serde" prints nothing same for tempfile

[sturdy tapir]

this is what i get from rust analyzer

[limber wedge]

hm i assume you already cleaned your target folder? my ra seems fine

[twilit dew]

FWIW the latest rust version broke my cache somehow

So I got weird versions of bevy crates

Dunno if that’s what’s happening here though 🙂

[sturdy tapir]

i didnt even think bout rust update

ok
cargo clean
rustup update stable
and error persists

    Updating git repository `https://github.com/TheBevyFlock/bevy_cli.git`
    Updating crates.io index
error: failed to select a version for `tempfile`.
    ... required by package `cargo-generate v0.23.0`
    ... which satisfies dependency `cargo-generate = "^0.23"` of package `bevy_cli v0.1.0-alpha.1 (https://github.com/TheBevyFlock/bevy_cli.git?tag=cli-v0.1.0-alpha.1#2d12bc0e)`
    ... which satisfies git dependency `bevy_cli` of package `bevy_launcher v0.17.0-dev (/home/rin/Documents/RustDev/bevy_editor_main/bevyEditor/bins/bevy_launcher)`
versions that meet the requirements `~3.18` are: 3.18.0

all possible versions conflict with previously selected packages.

  previously selected package `tempfile v3.21.0`
    ... which satisfies dependency `tempfile = "^3.0"` (locked to 3.21.0) of package `proptest v1.7.0`
    ... which satisfies dependency `proptest = "^1"` (locked to 1.7.0) of package `bevy_render v0.17.0-dev (/home/rin/Documents/RustDev/bevy_editor_main/bevyEditor/crates/bevy_render)`
    ... which satisfies path dependency `bevy_render` (locked to 0.17.0-dev) of package `benches v0.0.0 (/home/rin/Documents/RustDev/bevy_editor_main/bevyEditor/benches)`

failed to select a version for `tempfile` which could resolve this conflict```

[limber wedge]

do you have an old lockfile?

[sturdy tapir]

that was it!

[sturdy tapir]

@pale viper is more planned to be set to pub for the cli?
seems like only things availble are

use bevy_cli::build::{args, build};
use bevy_cli::lint::{lint, LintArgs};
use bevy_cli::run::{run, RunArgs};
use bevy_cli::template::generate_template;```

seems like very little? atleast when i compare to what is claimed to be available

[pale viper]

I think we're open to it, but haven't really thought of anything concrete

Is there something you're missing / want more control over?

[sturdy tapir]

also the docs for gen template seem wrong?
theres no options to pass a None through?

[pale viper]

Huh, I think that may be outdated

We now have bevy_cli::commands::new::new()

[sturdy tapir]

tbf i did have to use the 0.1.0 version since i couldnt fine what commit to be on

[pale viper]

Ah, that makes sense! :)

[sturdy tapir]

ill keep trying to get on newer version

[pale viper]

Is there newer version still giving your version conflicts?

[foggy basin]

My stance on it is:
Whatever you need to be available we can make available.
What exactly are you looking for?

[sturdy tapir]

that was my intial assumption retrying now to see if that was wrong and it was just lockfile bad

[foggy basin]

The commands you have listed can basically do everything the CLI can do, pretty much everything just depends on how you configure the args
But if you need access to something lower level we could also make that available

[sturdy tapir]

Ill have to look at what the cli offers rn but, adding to template list, search/list availble templates etc

[pale viper]

Ok. We don't expose any template listing yet, but I can see that being useful

[pale viper]

If you can't get main to work, try release-v0.1.0-alpha.2 (18efa526e2e0c2150525a63f257fc59e846bb616) where I ran cargo update on all the lockfiles
Nevermind dependency lockfiles are ignored, so that won't work

[sturdy tapir]

ok main seems working, i guess it was just my lockfile that borked everything

[foggy basin]

There isn't really a template list right now.
Temppates are just git repositories and we have a shorter syntax for the ones in the BevyFlock organization
bevy new is essentially just cargo generate and I think we support the --path arg now.
So if you want to allow the user to create custom templates, you can just create a folder and then use the path with that

90% of the CLI is just calling other CLIs with the correct arguments

(Except for the linter)

[limber wedge]

doc comment is still wrong :(

[pale viper]

I'm opening a PR now lol

https://github.com/TheBevyFlock/bevy_cli/pull/604

[sturdy tapir]

use bevy_cli::commands::{
    build::{build, BuildArgs, BuildSubcommands, BuildWebArgs},
    completions::completions,
    lint::{lint, InstallArgs, LintArgs, LintSubcommands},
    new::{new, NewArgs},
    run::{run, RunArgs, RunSubcommands, RunWebArgs},
};``` 
ok thats not a bad list

ill have to search through it to learn some

[foggy basin]

If you need something else, please open an issue!

We could probably expose the external_cli stuff though.
Especially our wrapper for the external CLIs with auto install functionality would be useful in other contexts

[sturdy tapir]

yes please.
the launcher is gonna be the "non programers cli" essentially so all the stuff a bevy dev has to do in cli needs to be doable in the launcher
at least thats the goal

[foggy basin]

That should already be possible. The external CLI things are what's used inside the other commands that are already exposed publically.
For example, bevy build web uses cargo metadata, cargo build, wasm-bindgen and wasm-opt.

[sturdy tapir]

yea, but having it exposed through bevy_cli helps ensures i never go beyond what cli can do

launcher/editor are not allowed to have features that the coders dont have, its a rule to ensure we dont neglect the coder side of things

[foggy basin]

Yes, that would be handled by bevy_cli::build::build(args) which is pub already.
This function internally calls the other CLI tools.
So if you only want to do what the CLI can currently do, you should be good to go! :)

I also highly recommend to play around with the CLI commands with the --verbose flag, we try to be very transparent on what is being done internally.
The linter is probably less interesting for the launcher and more for CI / IDE. new is a thin wrapper around cargo generate. For the default build and run there is not much different than the cargo equivalents.
For build web and run web a lot more is going on.

Not relevant for this topic, but @pale viper @limber wedge what is the current state of making the linter independent of the bevy version? Is it a high complexity change?

I'm also wondering if commands like cargo +nightly ... require rustup or just need cargo. If yes, I think it would be easy to make the linter independent from having rustup installed

[rocky oxide]

https://github.com/bevyengine/bevy/pull/21162 discusses the bevy_cli in our migration guide; I would appreciate your eyes on this

[limber wedge]

Its very complex i dont think even clippy supports that they are just „lucky“ that rust is more stable

Im not even sure anymore if we do want to support multiple versions but it definitely needs a design document to make a decision

[limber wedge]

and if you have time this week could you give: https://github.com/TheBevyFlock/bevy_cli/pull/603 another look? 🥺

[rocky oxide]

Oh right, yes!

[pale viper]

Like what @limber wedge said, it is a high-complexity change, but I still want it to support long-term projects that can't upgrade as quickly. (Most likely, we'll have a policy that only supports a window of like 3 Bevy releases at a time)

I'm relatively certain the people at Foresight at behind a release or two (@vast vine maybe you can verify?) They might be interested in the linter for stricter checks

[pale viper]

cargo +nightly ... is syntax sugar for rustup run nightly cargo ..., so unfortunately that won't work

[vast vine]

We are about to merge our migration to 0.16 and will likely start migrating to 0.17 once it's released so we might finally catch up 😅

[pale viper]

What's the status with arctic_tern? Are you accepting contributions for 0.17?

[vast vine]

ast-grep isn't nearly as flexible as I had hoped unfortunately 🙁 . It's really hard to make some simple renaming rules. Each rules needs to live in a separate file which is really annoying. It's possible I'm just missing something though and I would absolutely love if other people were also looking into it

It was really useful for me when doing ad-hoc migrations and writing manual rules when needed but for making it general purpose it has been really painful

Like, enough that it would be easier to just write something manually using regexes

Technically it would be much nicer if I could write it using the api from rust, but they only have documented bindings to python and js despite the project itself being written in rust

I could use js to script things but I don't want to ask our users to setup a js environment just for this

[limber wedge]

Just write another rustc driver

[limber wedge]

I think python / js would be fine? The cli could still take care to set everything up and maybe clean it up again if prompted

[vast vine]

I hate setting up a python environment, especially on windows. Every time I had to it was painful. I also just don't get why people like it so much, I find it not fun to write at all but that's very subjective. As for js, I don't mind it that much but with all the recent npm supply chain issues many people will be quick to dismiss it.

[limber wedge]

Yea understandable

I was shocked when i wrote some python at work the workflow for me is so different. Normally I rely so heavily on the lsp to give me the documentation but with python there is nothing? You permanently need to open the website of the library you want to use

So yea i dont enjoy it either for more than simple scripts

[vast vine]

Even for scripting at this point I would pick rust. Especially once cargo-script finally becomes stable and supported by RA. For me, when writing short scripts all that matters is familiarity with the language and I know rust and it's ecosystem better than anything else so I'll most likely get something done faster using that. I wouldn't recommend using rust like that for everyone but I still think that the right tool for writing something quickly is the tool you know the most.

[crude mica]

Yeah i think fully investing in rust is a smart move

[pale viper]

One of my first ideas with the linter was to have a group of lints that specific helped with migrating to new Bevy versions

But due to the amount of breaking changes in Bevy and the complexity of writing lints, that's not in scope anymore 😅

[limber wedge]

Yea i think some would be really easy (when its just a method A is now B or type A is now B) while others would be really challenging

[rocky oxide]

Updating the date on https://github.com/TheBevyFlock/bevy_cli/pull/603/ and merging ❤️

I'm quite happy with the progress and the documentation 🙂

And very keen to have this ready for the 0.17 drop where we break everyone's web builds 🙃

[limber wedge]

Thank you!

[pale viper]

Thank you! I'll finish the release today during lunch :)

[pale viper]

The long-awaited release is finally here! :D

And https://github.com/TheBevyFlock/bevy_cli/pull/611 (the post-release PR) is now up! I'm going to sleep now, so I'm not going to announce the release on Mastodon until tomorrow

[pale viper]

I ran into our first bug of alpha 2! https://github.com/TheBevyFlock/bevy_cli/issues/612

It may be worth considering a patch release for this? I don't know if it has a big enough impact

[limber wedge]

Yea i think it would be worth it this is not usable otherwise

[pale viper]

Ok, #600 is merged so you all will need to rustup update the next time you checkout main, as the nightly version has been bumped

Also @limber wedge I finally got through all of #577 updating the linter to 0.17, so let me know if you have any questions related to my feedback

I'm going to take a stab at the bevy lint web getrandom bug, then maybe sketch out some testing infrastructure :)

[limber wedge]

Thank you! It was a pretty huge diff 😂 i will be pretty busy until Wednesday so if you have time feel free to help out!

[molten merlin]

does the linter currently work with 0.17? There seems to be a nightly toolchain issue

❯ bevy lint
error: rustc 1.86.0-nightly is not supported by the following packages:
  [email protected] requires rustc 1.88.0
  [email protected] requires rustc 1.88.0
  [email protected] requires rustc 1.88
Either upgrade rustc or select compatible dependency versions with
`cargo update <name>@<current-ver> --precise <compatible-ver>`
where `<compatible-ver>` is the latest version supporting rustc 1.86.0-nightly

Check failed: exit status: 101.
error: command `bevy_lint --profile dev` exited with status code exit status: 101

I'm using 1.90 stable and 1.92 nightly in my local toolchains

❯ cargo +nightly --version
cargo 1.92.0-nightly (966f94733 2025-09-16)

[molten merlin]

added PR for above error: https://github.com/TheBevyFlock/bevy_cli/pull/614

[limber wedge]

Not yet. This is the pr that will support bevy 0.17 https://github.com/TheBevyFlock/bevy_cli/pull/577

[pale viper]

I fixed up all the changes, so it should be good to merge now :)

[limber wedge]

Thank you a lot!

[limber wedge]

Yea i was looking into this a while back and imo its not as clean of a solution as i would like it to be

[pale viper]

@limber wedge @foggy basin now that the bevy lint web getrandom fix is merged, do you think we should publish another release?

[limber wedge]

I would say so. Its a bit sad that we dont have semver yet

[rocky oxide]

Using the CLI for engine dev today over in #assets-dev

Thank you for handling the getrandom nonsense

[snow linden]

(i am claping)

[rocky oxide]

https://github.com/TheBevyFlock/bevy_cli/issues/622 :p

[pale viper]

Good idea! I forgot that examples can “require” features

[rocky oxide]

@vast vine https://github.com/TheBevyFlock/bevy_cli/issues/623 🎟️

[shrewd monolith]

i think this might be a duplicate of https://github.com/TheBevyFlock/bevy_cli/issues/245 ? although it does mention that it may need to be specialized for the web

[rocky oxide]

Agreed; closing

[twilit dew]

this would be lovely to have in the bevy cli. Even for using it with non-bevy projects hehehe

[foggy basin]

Maybe a dumb question, but where are the required features defined?

[rocky oxide]

Cargo.toml

https://github.com/bevyengine/bevy/blob/329630c84a935c43801d37bb3a3bc1884e73d172/Cargo.toml#L1295

[elder mantle]

I'm trying to use the bevy cli to create a web build of my game, but it isn't creating a canvas despite Window.canvas being None
is there some other requirement for the canvas to be automatically created?

[elder mantle]

ah found the problem: it was automatically picking up my old index.html

[pale viper]

Ah, that'll do it! If you just upgraded the CLI, you might have hit #485, which lets web/index.html be specified at the package level

[elder mantle]

yup that's exactly it

[elder mantle]

having a focus ring around the canvas is pretty odd, is that avoidable?

would y'all be happy to add this to the default css?

canvas {
  outline: none;
}

[twilit dew]

I would like that

[elder mantle]

made a pr 🫡

[near mist]

lol if you add restriction = "warn" to your Cargo.toml, you'll get warnings for using Update and/or FixedUpdate

i guess that's fine, you just have to opt in to specific restriction lints and not the whole category. need a Cargo.toml linter that tells me not to activate the whole category

i was confused why i started getting "Update schedule is disallowed" warnings in my CI 😄

[limber wedge]

Hahaa yea they are really not ment to be enabled as a group

[elder mantle]

yeah that's also how clippy's restrictions category works

[pale viper]

Here's something cool that I found: https://github.com/Rust-for-Linux/klint

It's a Rust linter specific to the Linux Kernel, we maybe be able to take some inspiration from what they've built

https://lwn.net/SubscriberLink/1038750/6aa9769e0b875235/

[limber wedge]

I saw that too its pretty cool but i think our setup is a bit more modern

[pale viper]

@foggy basin and @limber wedge, I'm almost done with the rough draft for the CLI and linter upstream document. Could you please give https://hackmd.io/y1J-r9y8TQClRjOEMeiQkA a read through and leave your thoughts and feedback? I want to know your thoughts on what I have proposed before we put it in front of the maintainers

Feel free to make edits to the document itself! If you're not in the Bevy HackMD org yet, the join link is https://hackmd.io/join/B1PtvsG_R

[rocky oxide]

https://github.com/bevyengine/bevy/issues/21369

This is relevant to y'all, because of how much running examples with non-default features sucks

[limber wedge]

Will have a look later today! I finally set up my pc at my new apartment

[foggy basin]

I tackled some low-hanging fruit to reduce the CLI's dependencies:
https://github.com/TheBevyFlock/bevy_cli/pull/627
Was able to remove 33 dependencies and 0.6M file size. Not amazing, but it's a start :)

[limber wedge]

left some notes and i think you summed it up really nicely!

[pale viper]

Awesome! I noticed you disabled for basically all of our dependencies, even crates that don't have default features

Like clap_complete doesn't have any default features, yet you set default-features = false

Was there a specific reason you did this? Is there a benefit to doing it as compared to the normal clap_complete = "4.5.58"?

[foggy basin]

Yea, I thought that makes it easier to track where unnecessary features might still be enabled.
Also when we update the depenendency and it added any new default features, we won't pick them up

But it's not a strong preference, if you prefer to omit it I can change it back :)

[pale viper]

I don't think I have a strong preference, I just want it to be consistent

Not required, but do you think you might be able to add a quick page to our contributors guide on dependencies?

Basically just saying to set default-features = false for all dependencies, and incrementally enable features as needed

[foggy basin]

Sure! I'll to that tomorrow

[foggy basin]

Seems like the toml snippet isn't working in all cases for get random 0.2

[lime falcon]

fwiw, my project is a workspace if that throws a wrench in this kind of check.

[pale viper]

What does bevy build web --verbose say? Verbose logging should tell what the CLI is doing under the hood

[lime falcon]

Ah, no, I just missed the whole snippet (and I had similar config to the snippet, but because it wasn't working I glazed over it)

My apologies

logs show the snippet was showing up.

Though it does not show up "like an error/suggestion" compared to the rustc errors & suggestions, so best I can do is tuck my tail between my legs and suggest it should look more like the suggestions rustc gives 😅

[pale viper]

Hmmmm I bet we could use annotate_snippets for this

[foggy basin]

Yea it's definitely not as visible as it should be. We planned to add some syntax highlighting, but tracing stripped out the formatting

[foggy basin]

That looks interesting. Although I'm not sure which line number we would use, since this would be a new addition to the toml

[vague brook]

hi, bevy -p game_client build web --bundle copy automatically the whole web folder ? my build is in target/bevy_build/web/game_client/build, and here the game_client directory is copied from the web directory at the root of my workspace.

its not preventing anything to work, just wondering if its on purpose ? my web folder has a whole web app, android and ios project, so its quite big.

thanks :)

[foggy basin]

Yes that's intentional, we assume all assets that you need for your web app to work to be located in the web folder.
The use-case is then that you can zip it up and serve it on your web server.
Which behavior would you have expected in your case?

[limber wedge]

relates to: https://github.com/TheBevyFlock/bevy_cli/issues/484

[vague brook]

oh ok useful !

[vague brook]

thanks thats it !

for my use case, even disabling totally the web folder would be good, because i manually copy the bevy build output to my web app, as my build process has many other part i use a makefile anyway

.
my client binary crate depends on a shared lib crate where most of the bevy code is, when using bevy lint -p client will it also lint the shared crate ?

also im having this fun error when running with cranelift:

error: multiple input filenames provided (first two filenames are `x86_64-unknown-linux-gnu` and `-`)

error: Failed to assemble `.globl __inline_asm_cfd6pnssq73z751dkscjvsef6_n0
[...]

[foggy basin]

I see! Yeah tbh, the CLI's support for complex project setups is quite limited as of now. That's definitely an area we can improve on :)

[vague brook]

no honestly its excellent, it just build the app and works well. the other steps are not required, if the user has a complex project setup it always need some glue anyway, bevy cli can't handle all the use cases, it always require some make/justfile or similar

[vague brook]

you want a gh issue ?
full log:

[foggy basin]

Yes please :)

[foggy basin]

The contributing guide right now seems to be specific to the linter, so for now I added it to CONTRIBUTING.md. Let me know if I should put it elsewhere :)

Ah nevermind, we also have one for the main CLI, it's just not linked in CONTRIBUTING.md. Let me fix that

[foggy basin]

I also left two comments :)

[limber wedge]

testing bevy build --examples on the bevy repo is not the best way to test this

[foggy basin]

I'm happy when I finally get time to assemble my new PC parts and don't have to spend half my time compiling various packages with the CLI :D

But at this rate it seems like one needs a separate 2 TB SSD just for Bevy haha

[limber wedge]

yep those 300GiB are not even all examples (it crashed before that) xD

[pale viper]

Dang, definitely disable debug info when doing that, as it can double / triple your binary size

[rocky oxide]

ahahaha

That's great

[rocky oxide]

I feel like maybe this is not a useful feature on the main Bevy repo 😅

[limber wedge]

Hahaha yea its not😂

[limber wedge]

https://github.com/TheBevyFlock/bevy_cli/pull/629 tries to align bevy build and bevy lint more with cargo. Before that it was only possible to lint or build binaries / one example.

[foggy basin]

Oh I'm curious to see how you do it :)
I think we have a super old issue about this, but I always dreaded to implement it

[limber wedge]

well i more or less just copies your code lol

im not sure what behavior makes sense for the web. i think ideally we would support compiling (and resolving) packages the same way as we do native but maybe as an extra flag? --no-bundle or --only-compile idk

[foggy basin]

I think we can just do the same behavior as on native, right? Since --bundle is a separate arg anyway I think we need no extra flags

In the future, I highly suspect the bundling will be a separate command anyway

[limber wedge]

yea but not sure how much sense wasm_bindgen::bundle makes for none runnable packages.

[foggy basin]

That's a good point

[limber wedge]

https://github.com/TheBevyFlock/bevy_cli/pull/636 🎉

[foggy basin]

Awesome, you're on a run
Sorry for the slow reviews currently, I hope I'll have some time soon :)

[limber wedge]

i dont have internet yet and my hotspot is so bad that there is not much else to do ^^

[foggy basin]

Fair, a productive use of time!

I could only do a quick phone review, but is that data also available on the BinTarget?
Then we might not have to search for the target again and it would work for all targets instead of "just" examples

[limber wedge]

i saw now that cart was not a fan of enabling automatically, did this change? https://github.com/rust-lang/cargo/issues/4663#issuecomment-3250715703

[limber wedge]

Yes it is but im trying to get rid of BinTarget for native builds so we can support none binary targets lol

[limber wedge]

better take some time to think / play around with it a bit we dont have to rush <3

[rocky oxide]

As long as it's not silent it can probably be tolerated, but a y/n prompt may be nicer

[limber wedge]

i will add a prompt tomorrow 👍

[acoustic wraith]

chello, clapping as requested 👏

is it possible to customize the HTML/CSS used for bevy build|run web?

(apart from patching things up after bundling, that isn't sustainable for me)

[twilit dew]

IIRC the CLI will pick up your HTML / CSS from a specific folder and only provide its own if it couldn't find anything

so you could copy-paste the default HTML+CSS into your own project and tinker with it to your heart's content

[pale viper]

Yup! As Jan said, you can create a web/index.html file that the CLI will use instead of its default one

Check out https://thebevyflock.github.io/bevy_cli/cli/web/default-index-html.html. I recommend copying the default and modifying it with your changes

Watch out for import init from "./build/bevy_app.js";, though! You'll need to change bevy_app to your binary's name :)

[acoustic wraith]

cheers folks, gonna try that out

I only tried the cli's builtin help, that doc site is sure gonna come in handy

[near mist]

is there an issue for a command to do this automatically?

yes there is: https://github.com/TheBevyFlock/bevy_cli/issues/224

[pale viper]

@molten merlin do you want me to adopt https://github.com/TheBevyFlock/bevy_cli/pull/614 ?

[molten merlin]

isn't it ready to merge? or is there more you wanted

I can hit commit on the version suggestion if that's what you mean

I can't adjust tags in that repo (don't have permissions), so can't take "waiting on author" away

I pushed a commit removing the version

[pale viper]

Only copying the changes to quick-start.md, I'm happy with the rest :)

We try to keep the README.md in sync with the website docs

[molten merlin]

thebevyflock seems to have a "manually update in multiple places" issue 😅

I've pushed a commit

the templates also use the same Cargo.toml/Cargo.toml.template file, which requires manually mirroring code between them

[pale viper]

Hah, I've noticed that too!

We do pretty well at maintaining a single point of truth, but there are definite exceptions like the README.md / docs desync

[twilit dew]

Yeah I hate it

(in the templates's cases)

[pale viper]

What if, for bevy_new_2d, contributors wishing to work on the template itself had to generate a new Cargo.toml when they checkout the repo?

Like, what if Cargo.toml was in .gitignore?

[twilit dew]

it makes our own CI more difficult

it's all doable

[pale viper]

That way we only track Cargo.toml.template

[twilit dew]

but very annoying

but yeah I would probably approve such a PR

[pale viper]

It feels like the more we customize it to work with cargo-generate, the harder it is to use the template without

But I guess that's a given 😅

[twilit dew]

yeah agreed. I think it's a fine tradeoff 🙂

But definitely something to keep in mind

[molten merlin]

I don't think using the template without cargo-generate/bevy-cli is a use case tbh

[pale viper]

Here's an idea for CI: instead of running cargo build etc. on the template itself, it first uses cargo-generate to create a new project with the default values, then runs cargo build on that

[twilit dew]

At least I am not aware of anyone who does, but we still get regular forks, so /shrug

definitely wouldn't recommend it

[twilit dew]

yep that makes sense

I also wish we had a way to get rid of Cargo.toml.template

could run some crappy custom search/replace on it

since cargo-generate allows arbitrary command execution

or maybe run it as a Rhai script

idk

I don't want to touch Rhai

but it sounds doable

[twilit dew]

Yeah IIRC you can run Rhai scripts as post-install hooks

Not something I have much time for right now

but if there's a secret Rhai aficionado under us... 👀

[molten merlin]

why are we considering .template needed? tbh I don't really have opinions on its inclusion in bevy_new_2d because I don't plan to contribute much there, but its pure overhead for the minimal template

[twilit dew]

I thought maybe we could get rid of that by using a placeholder like crate_name and author in the regular Cargo.toml and then using a Rhai hook to search/replace it

[twilit dew]

And yes, I hate the overhead too. We deemed the overhead a good tradeoff for the user experience, but it's very

[molten merlin]

I guess I'm not following since this is just a photo. The template is the critical piece of the repo. So the duplication is having a random "other" Cargo.toml that isn't the template

like you don't need a .template extension for cargo generate to work

[twilit dew]

we had issues with exactly that when trying to fill out stuff in a .toml

don't remember what exactly

[molten merlin]

yeah ok, its not that important so feel free to just leave it

just weird to get bounced back on multiple prs this week that are effectively "could you copy paste this to this other file that's the same file but in a different location"

[twilit dew]

Yeah I'd be happy to see it go too

[twilit dew]

the photo is just the relevant part of the Cargo.toml.template 🙂

[twilit dew]

I've also run into multiple cases of merging something and then forgetting to add it to the .template too, which meant that the changes didn't actually land for any users

[twilit dew]

yeah their examples clearly show that the .toml replacement should work

@near mist do you remember why we didn't do that?

[near mist]

because that's not a valid Cargo.toml

[twilit dew]

Oh probably because the name "{{project-name}}" makes the IDE very angry when locally changing it

[molten merlin]

it definitely works: https://github.com/rust-adventure/skein/blob/template-minimal/Cargo.toml#L2

[twilit dew]

I suppose your rust-analyzer doesn't like that, right?

when working on the template itself, I mean

(not saying it's a bad idea, just trying to remember our reasoning)

[molten merlin]

running a template like its a regular project means you can't use templating in any of the other files, so isn't really a solution to the problem

[near mist]

we wanted to be able to work on the template with tooling like rust-analyzer and cargo functioning

[twilit dew]

yeah that makes sense now

[near mist]

for bevy_new_minimal that's not as useful because it's so simple you can't really mess it up

[twilit dew]

yeah agreed

let's yeet it from there

Up for grabs https://github.com/TheBevyFlock/bevy_new_minimal/issues/23

I think it's only the Cargo.toml.template

[near mist]

you can but you need to create a .template version of the file any time you want to do that :p

[molten merlin]

hrm? https://github.com/cargo-generate/cargo-generate/blob/5b53d156920e7621620798cbb2e1257efc601abc/example-templates/placeholders/src/main.rs

the .template files are firmly a choice the thebevyflock repos make, they aren't required

[near mist]

i know

i mean you can still use template features without breaking the build for template developers by doing it in a separate file

[twilit dew]

Yeah, Pyrious' point is that you can use the template with the regular rust workflow tools. You just need to use .template as a tradeoff.

Which I agree is not worth it for the minimal template 🙂

[molten merlin]

just for my own clarity: you're saying that to get it to work, you have to create and manually update a second file with the changes you're making to the real source file

[twilit dew]

bingo

and yes, you have clearly spotted the obvious issue with that haha

[molten merlin]

yeah, you're basically laying a different project over the top of the template instead of... using the template

[twilit dew]

pretty much, yeah 🙂 but I think that's a little bit of an uncharitable view of it

[near mist]

yeah i don't know how other large cargo-generate templates are maintained. they don't use this pattern but that means they have to maintain their codebase with no tooling

maybe they make some changes, run cargo-generate locally, and then test the resulting project

[molten merlin]

yeah anyway, like I said feel free to keep doing what y'all want to do, but it is weird and doesn't seem to actually solve the issue

[twilit dew]

and run rustfmt and clippy on that I suppose

[molten merlin]

you still have to copy/paste the code

[twilit dew]

I'm very open to alternatives

of which the best is probably "run cargo-generate in CI and validate that clippy and co like the output"

[near mist]

(which we should be doing anyways, but i haven't gotten around to)

[twilit dew]

yeah once we have that we can cargo-generate locally

[near mist]

we almost have it in bevy_new_minimal but it doesn't run clippy etc on the generated project, it just diffs its files with the template

[twilit dew]

I'm a bit surprised tbh that this fairly obvious thing doesn't seem to have an official solution

But I suppose it's hard to come up with good placeholder symbols

[near mist]

i am too. i don't think i found any discussion about it either

[twilit dew]

I think __foo__ ought to work better

(if cargo likes that name)

indeed it does

cargo new __foo__ works as expected

[twilit dew]

We could use a hook to replace those symbols in the .tomls

[near mist]

like a pre-generate hook to replace bevy_new_2d with {{project-name}}?

[twilit dew]

wouldn't work for .rs files ofc

[twilit dew]

something like that

or a post-generate hook to replace it

if that's possible

it would be a weird hack

[near mist]

ah actually i remembered hooks require users to approve :')

i mean

general commands in hooks*

[twilit dew]

baaah

cargo-generate why do you have to be so impractical ;-;

[near mist]

security 😡

[twilit dew]

[near mist]

also that would help with the most common case of {{project-name}}, but not other templating features

[twilit dew]

Let's see if we can try out the local generate + CI validation variant for the next jam

which is historically when we actually work on the template haha

something something a running system

[near mist]

the question is whether that would be more comfortable for maintainers / contributors, because all of this doesn't affect users of the template

compared to the current approach

[twilit dew]

yeah I'm curious too, I can see it going both ways

but worth a try imo

It at least should make it more obvious for contributors like @molten merlin what's going on

even if Chris himself doesn't want to contribute to the 2D template, I think his experience is a good measuring stick

@pale viper sorry for brigading this chat with template stuff btw hehe

[near mist]

oh i didn't realize this was the cli chat 😅

[limber wedge]

I would like to bring this up again: https://github.com/TheBevyFlock/bevy_cli/pull/636#issuecomment-3374769749 and get a feeling what the desired result would be from the maintainers pov. I think prompting makes sense but we could open an issue to add (in a future global cli config file) a setting to „always enable required features“.

I think Bd has a point that it could be really annoying for experienced users or result in them just always pass —yes to skip prompts

[foggy basin]

Tbh I'm skeptical of a prompt for this. In which case would a user actually want to cancel the action due to the required features?
I feel like you would always want to confirm the prompt, making it annoying rather than useful.
Definitely agree though that it should be communicated to the user.
An info log sounds like the better way to do this though IMO

[limber wedge]

Card just voiced concerns that it could lead to recompiles of bevy (that can take a long time) and new users would maybe not understand why. A simple log could also get lost in all the cargo output

enabling + logging is also my favorite

[foggy basin]

IMO compilation is expected when you run an example
If it takes longer than expected, the cargo logs will tell you that it needed to recompile bevy and our log will tell you why

[rocky oxide]

That's my opinion too

We could also do a yes/no/always prompt, but that's pointless complexity if everyone always says always

[limber wedge]

well... i have internet now but thats not what i expected (i should have 10G)

[twilit dew]

in case any of you want to add support for bevy build web --bundle to serve the multithreaded audio on GitHub pages

which bevy_new_2d now supports deployment to 🙂

[pale viper]

*laughs in ethernet*

The only thing slowing me down is the fact that I use a gigabit network switch, and share it with my server

[limber wedge]

Just wait til i have it fixed

[lusty idol]

Hi, question about the possibility of a lint:

Checking whether systems appear in schedule order. For example systems in startup schedules appear in order, and systems in PreUpdate appear before Update appear before PostUpdate etc.
Might not be possible for custom schedules but for the native ones it might.

Is it possible? Is it too opinionated to be worth having?

[pale viper]

I think that makes sense, but could you give a code example so I can better wrap my head around it? (Like a before and after, similar to our examples?)

[lusty idol]

fn main() {
    App::new()
        .add_systems(Startup, setup)
        .add_systems(Update, bar)
        .add_systems(Update, foo)
        .run();
}

fn foo() {}
fn bar() {}

fn setup() {}

For example this has two problems (arguably):

1. bar is added before foo, but defined in the opposite order
2. setup is added first, but defined after

A similar lint could be that .add_systems should add things in schedule order

So e.g.

fn main() {
    App::new()
        // bad: bar runs in a later schedule but added first
        .add_systems(PostUpdate, bar)
        .add_systems(PreUpdate, foo)
        .run();
}

[limber wedge]

I can see this more. The first one seems not as useful to me since systems can be defined anywhere and the actual declaration order does not matter. I would argue if you are searching for a system you either search by document symbols or by goto definition so i dont think it has a cognitive overhead if they are not defined in order

[lusty idol]

Personally I'd like systems defined in the same file to be defined in the order they are added, but I can understand if that's too opinionated

[limber wedge]

But i think ordering the add_systems by schedule makes sense

[lusty idol]

I'd like both

[dapper yew]

@craggy valley I tested your patch and it needs a slight fix, but I think it's very valuable, so I recommend we merge https://github.com/TheBevyFlock/bevy_cli/pull/532

[craggy valley]

Awesome, thanks so much for taking a look at this. I really appreciate it.

[whole iris]

Hi when using bevy run web I get

rror: the wasm*-unknown-unknown targets are not supported by default, you may need to enable the "js" feature. For more information see: https://docs.rs/getrandom/#webassembly-support
   --> /Users/x/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/getrandom-0.2.16/src/lib.rs:346:9
    |
346 | /         compile_error!("the wasm*-unknown-unknown targets are not supported by \
347 | |                         default, you may need to enable the \"js\" feature. \
348 | |                         For more information see: \
349 | |                         https://docs.rs/getrandom/#webassembly-support");

I'm on version cli-v0.1.0-alpha.2

It still doesn't work if I use RUSTFLAGS='--cfg getrandom_backend="wasm_js"'

I have both getrandom=0.2.6 and getrandom=0.3.3 in my deps

[limber wedge]

I think you need to enable the „js“ feature. The snipped is not that visible

[whole iris]

I guess the issue is that I need the wasm_js feature for getrandom=0.3.3 and js for getrandom=0.2.6

[lime falcon]

getrandom delenda est. I had to add #1404237363550486751 message in the end

I had the same issue

[silk delta]

v0.3 really shat the bed. I can't wait to PR all the deps to fix it when v0.4 hits

Or they could do the funny and push the fix as a patch release

[limber wedge]

@thick elk is your project open source?

i can take a look after dinner

[thick elk]

Its only repo is on my computer

I can put it on github for you! What is your username on there?

[limber wedge]

https://github.com/DaAlbrecht but only if you feel comfortable

but in theory the cli will behave the same for game assets regardless if you build for web or not

[thick elk]

I'm super comfortable with it! I'm working on some Nix stuff with bevy, so some part of me thinks that it might be something in there that is causing this

But i'd love for you to check if it works on your machine!

[limber wedge]

nice thanks!

[thick elk]

I have invited you to the repo now!

You can share it with anyone you like, I just don't want it on my profile right now

[limber wedge]

what browser do you use?

[thick elk]

Firefox, but I've also tested it on Chromium

I can try full-on Google Chrome?

Same result on Google Chrome

Console log says this on grey screen:

Same error on Firefox

[limber wedge]

I think the problem is bevy_dev_tools

[thick elk]

You are completely right! My dice aren't loading now but everything shows up now

Thank you so much! My Nix wasn't the problem! Woohoooo!!!!!!!!!!!

[limber wedge]

https://github.com/bevyengine/bevy/issues/21362

this is the issue to it

[limber wedge]

@pale viper if you have time and energy can you take a look at: https://github.com/TheBevyFlock/bevy_cli/pull/639 this is surprisingly tricky because bevy::platform::time::Instant results in std::time::Instant after full path resolution. maybe im missing something ^^

the main problem is.. how to distinguish the two if they are not used in their fully qualified format.

[pale viper]

Hm... if I understand correctly, is it because bevy_platform::time::Instant is a type alias to std::time::Instant?

You won't be able to use rustc_middle::ty::Ty for that, because I don't think type aliases don't exist at that level

I think you need to resolve the hir::Ty into a Res, match it to a Res::Def, then check if the containing DefKind is a DefKind::TyAlias

Something like:

let as_unambig_ty: rustc_hir::Ty = hir_ty.as_unambig_ty();
let TyKind::Path(qpath) = as_unambig_ty.kind else { ... };
let res = cx.qpath_res(qpath, as_unambig_ty.hir_id);
let Res::Def(DefKind::TyAlias, _) = res else { ... };

// At this point, the `Ty` is definitely a type alias.

Once you've checked that the type is an alias, you can probably check that it is std::time::Instant and not bevy_platform::time::Instant by looking at the QPath. You should be able to use qpath_res() to find the DefId, which you can then check if it matches std::time::Instant's DefId

Instant is a diagnostic item, so it should be pretty easy to get its DefId: tcx.get_diagnostic_item(sym::Instant).unwrap()

I hope that helps! I don't think you can avoid special-casing it, but doing so will avoid false positives that you might be running into

[limber wedge]

Oh i think thats it!

Ye i did more or less exactly this at one point but i did Def(_, def_id) and didn’t see that there is a variant for tyalias. thanks i think this helps a lot!

[silk delta]

!!! They are doing the funni!!! https://github.com/rust-random/getrandom/pull/735

[pale viper]

No way, that’s crazy!

[foggy basin]

The feature is still required, which a couple of people ran into.
But that's something we can probably fix via the Bevy web feature

[silk delta]

The feature was required for v0.2 anyway, so this would be a return to normal

because wasm32-unknown-unknown is not actually a web target

[foggy basin]

Yea it makes sense

I wonder if we will ever get a dedicated web wasm target

[twilit dew]

WHAT?!?!‽
I did not see this coming, holy shit

[silk delta]

christmas coming early

[twilit dew]

@rocky oxide you'll like this

[rocky oxide]

Holy shit they're fixing it in a minor version

[twilit dew]

For real. First symphonia released a patch 3 days ago removing their 80 lines of logs per startup you get from bevy_seedling, now this?

[rocky oxide]

<@&1064695155975803020> 🎉

Minor version fix is so much better for us

Since then we don't need to wait for a cycle

Do we need to specify a feature somewhere?

[twilit dew]

Yes

But no rustflags

[pale viper]

But we already specify that feature in Bevy 0.17 I believe

[rocky oxide]

Oh good

[twilit dew]

I believe so too

So ideally things should Just Work for users

[rocky oxide]

If we need to I will push for an urgent point release to unbreak this

This is a major improvement

[twilit dew]

Just checked, bevy_platform activates the feature 🙂

But it’s optional

Oh and the bevy crate itself too only dev deps

That seems weird

I would make the dependency on getrandom nonoptional in bevy_platform when targeting wasm

[rocky oxide]

In theory we can target non-JS wasm!

But maybe the right call

[twilit dew]

Fair

[twilit dew]

Let me see if that dep is on by default

[snow linden]

bevy_platform should have a web feature that we can use for this, i think.

[twilit dew]

Meh, it’s behind the web feature

[twilit dew]

Yep

I wish this was Just Working though

[snow linden]

we can straighten this out in the next proper release

[twilit dew]

Without the Bevy CLI

[twilit dew]

@snow linden ^

[snow linden]

yeah, agreed. for now we should get the web working, and we can get the proper web platform flags later.

the web is such a feature compatability nightmare

[rocky oxide]

Using Cart's new "feature groups" idea would work well for this

[shrewd monolith]

-# it’s (almost) sad that they fixed it already, since you guys put a bunch of work into the workaround

[twilit dew]

That effort is still in use for the multithreaded audio 🙂

That also needs to set weird compiler stuff

[foggy basin]

Good thing we want to support every bevy version, so we can keep it forever if the offending get random version is in the tree :D

[rigid bluff]

Hello, when I add this dependency to my cargo.toml:

webrtc = { version = "0.10", features = ["data-channels", "wasm"] }

I get this when I run bevy run web :

Error: Failed to parse `cargo metadata` output

Caused by:
    EOF while parsing a value at line 1 column 0

Is that normal ? is there a workaround ?

[limber wedge]

Whats the output of cargo metadata?

[rigid bluff]

when you say it like that it seems obvious what the problem is, thank you

[pale viper]

Did you manage to get it fixed?

[rigid bluff]

yes, was bad crate import

[pale viper]

Cool, glad you figured it out :)

[vague brook]

hello ! ive renamed my project from ~/dev/waykeepers to ~/dev/waykeepers/main and now bevy build -p game_client web --wasm-opt false --bundle -v error:

info: bundling JavaScript bindings...
debug: running: `wasm-bindgen --no-typescript --out-name game_client --out-dir /home/mirsella/dev/waykeepers/main/target/wasm32-unknown-unknown/web --target web /home/mirsella/dev/waykeepers/main/target/wasm32-unknown-unknown/web/game_client.wasm`
info: using workspace assets.
info: using custom workspace web assets.
warning: custom web assets don't contain index.html, using default.
debug: copying build artifacts from file:///home/mirsella/dev/waykeepers/main/target/wasm32-unknown-unknown/web
debug: copying snippets from file:///home/mirsella/dev/waykeepers/main/target/wasm32-unknown-unknown/web/snippets
debug: copying assets from file://assets
debug: copying custom web assets from file:///home/mirsella/dev/waykeepers/main/web
error: failed to create web bundle

Caused by:
    0: failed to copy custom web assets
    1: No such file or directory (os error 2)

of course moving back the project to the previous directory works. ive tried deleting target multiples times :)

thanks !

[pale viper]

Hm, looks like there was an issue copying web assets

I made a branch of the CLI that outputs a bit more information, could you please install it and try it out?

cargo install --git https://github.com/TheBevyFlock/bevy_cli --branch fix-copying-web-assets --locked bevy_cli

For context, these are the changes I made

[limber wedge]

I wonder if your web folder has different permissions? Maybe an ls -all could be interesting too

[vague brook]

error: failed to create web bundle

Caused by:
    0: failed to copy custom web assets from file:///home/mirsella/dev/waykeepers/main/web to file:///home/mirsella/dev/waykeepers/main/target/bevy_web/web/game_client
    1: No such file or directory (os error 2)
main on  main [?] via 🦀 v1.92.0-nightly took 5s851ms
 1 ❯ stat /home/mirsella/dev/waykeepers/main/web
  File: /home/mirsella/dev/waykeepers/main/web
  Size: 632             Blocks: 0          IO Block: 4096   directory
Device: 0,40    Inode: 51548002    Links: 1
Access: (0755/drwxr-xr-x)  Uid: ( 1000/mirsella)   Gid: ( 1000/mirsella)
Access: 2025-10-16 17:18:08.134436374 +0200
Modify: 2025-10-16 17:18:08.118436331 +0200
Change: 2025-10-16 17:18:08.118436331 +0200
 Birth: 2025-10-16 15:04:31.467549261 +0200
main on  main [?] via 🦀 v1.92.0-nightly took 13ms
❯ stat /home/mirsella/dev/waykeepers/main/target/bevy_web/web/game_client
  File: /home/mirsella/dev/waykeepers/main/target/bevy_web/web/game_client
  Size: 22              Blocks: 0          IO Block: 4096   directory
Device: 0,40    Inode: 54414525    Links: 1
Access: (0755/drwxr-xr-x)  Uid: ( 1000/mirsella)   Gid: ( 1000/mirsella)
Access: 2025-10-16 17:33:20.051103251 +0200
Modify: 2025-10-16 17:33:20.057103261 +0200
Change: 2025-10-16 17:33:20.057103261 +0200
 Birth: 2025-10-16 17:33:20.051103251 +0200

[vague brook]

i used mv so the perms shouldn't change ?

both files exists and have rw permissions, weird

[limber wedge]

i dont think it does yea

is your repo public? i could try

[vague brook]

nop, ill try to do a repro

[limber wedge]

im a bit tired atm but quickly tried this and i dont think this is possible in a LateLintPass. The def_id already points to std::time and the kind is struct so i guess it already resolved the reexport.

        let ty = ty_from_hir_ty(cx, as_unambig_ty);

        let TyKind::Path(qpath) = &as_unambig_ty.kind else {
            return;
        };

        let res = cx.qpath_res(qpath, as_unambig_ty.hir_id);

        let Res::Def(kind, def_id) = res else {
            return;
        };

        dbg!(kind);
        dbg!(def_id);

output:
[bevy_lint/src/lints/style/bevy_platform_alternative_exists.rs:47:9] kind = Struct
[bevy_lint/src/lints/style/bevy_platform_alternative_exists.rs:48:9] def_id = DefId(1:10420 ~ std[e3da]Instant)

test:

#![feature(register_tool)]
#![register_tool(bevy)]
#![deny(bevy::bevy_platform_alternative_exists)]

fn main() {
    let _bevy_time = bevy::platform::time::Instant::now();
}```

(nitro please xD)

[pale viper]

Dang, sorry! I really thought that would work

Let me ask on Rust's Zulip, see if they have anything to say about it

(Do you have an account on the Zulip? I can ping you in the thread)

Oh wait! bevy_platform::time::Instant isn't a type alias!

//! Provides `Instant` for all platforms.

pub use time::Instant;

crate::cfg::switch! {
    crate::cfg::web => {
        use web_time as time;
    }
    crate::cfg::std => {
        use std::time;
    }
    _ => {
        mod fallback;

        use fallback as time;
    }
}

^ This is bevy_platform::time's source code. It's re-exporting std::time when not on the web

Rather than looking at the type or DefId, you're going to need to look at the path, since that's the only thing differentiating the two

[limber wedge]

Eh not yet but i should create one ngl

[limber wedge]

Yes but that does not work

Since if you do not use the fully qualified path you only have these segments for example: time::Instant::now and how do you know then if it wad std::time or bevy::time

[limber wedge]

(Squishy would be my zulip handle)

[lusty idol]

Does anyone have a gh workflow that helps host a bevy cli built app via gh pages?

[limber wedge]

I think the 2d template had an open pr for this maybe its already merged

Yep see: https://github.com/TheBevyFlock/bevy_new_2d/pull/465

[lusty idol]

Thanks, that's very timely!

[dapper yew]

I just ran into some weirdness around wasm-opt

$ bevy build web --wasm-opt "-Oz -all"
...
info: optimizing with wasm-opt...
Unknown option '-Oz -all'
warning: failed to run wasm-opt, trying to find automatic fix...
error: command `wasm-opt --output <output> <input> -Oz -all` exited with status code exit status: 1
$ bevy build web --wasm-opt -Oz --wasm-opt -all
...
info: optimizing with wasm-opt...
info: finished in 6.51s. Size reduced by 23%.
info: using package assets.
info: no custom web assets found, using defaults.

So the problem is that when you provide "-Oz -all" it considers it to be a single argument (and then lies about separating them in the debug log lol)
Is it worth me making a fix that splits the arguments by whitespace? It's kind of brittle, but I think it's better than the current situation maybe?

[limber wedge]

hm i would like to keep the default clap behavior. Maybe a PR that points this out in the docs would be cool

[dapper yew]

How about a help message when the command fails that says something along the lines of

hint: The wasm-opt argument contains a space: `-Oz -all` if this is not intentional, consider using a `--wasm-opt` for each:
bevy build web --wasm-opt -Oz --wasm-opt -all
(And the output at the end would be verbatim what the user provided, except with the wasm-opt options split out?) Then it's only a hint in case of failure

[vague brook]

ohh found my problem using strace, in my web dir the dist dir is a symlink with absolute path to .output/ public (nuxtjs does this) and the symlink is broken after the rename since its a absolute path. so fs_extra errors when copying the symlink

[dapper yew]

This actually looks way better to me than just quietly separating the users arguments (and then providing no way to stop the splitting)

[pale viper]

I’m glad you figured it out!

[vague brook]

should i open a issue about failing to copy dir if there's a broken symlink somewhere in the directory ?

[dapper yew]

If there are any big objects to this I'll try implementing it, this seems much less controversial than splitting the arguments at least

[pale viper]

Personally I think the issue is a bit too niche to warrant special-casing it in the CLI, but if it pops up again in the future I'd definitely consider it!

[vague brook]

ok, especially that its in fs_extra. the main problem imo is the opaque error message, fs_extra doesn't return which file errored in the log

[pale viper]

Hmm, looks like fs_extra is abandoned / unmaintained. If we wanted to improve the error messages, we'd have to make our own abstractions

[pale viper]

If we had more access to the import resolution logic, we might be able to figure it out, but it looks like most of it is pub(crate) in rustc_resolve

Honestly, with how hard a problem this is, I'd skip it for now and mark it as a known issue

You should totally ask around on the Zulip if you want to pursue it further, though! The Clippy and Compiler/help channels are where I'd go

[dapper yew]

Hi, how does bevy_cli work with regards to profiles and stuff? I did a --verbose run, and the command I got is
cargo build --config profile.web-release.inherits="release" --config profile.web-release.opt-level="s" --config profile.web-release.strip="debuginfo" --profile web --target wasm32-unknown-unknown
All of which I understand except how profile.web-release can affect the web

[pale viper]

When you build for the web using the Bevy CLI, it will use the web profile in dev mode and web-release in release mode

By the looks of things, it appears that you have a [profile.web] entry in your Cargo.toml

The web-release profile by default strips debug info and sets opt-level = "s" to optimize builds for size

(And web-release inherits the normal release profile too)

Does that answer you question? Are you running into any issues?

[limber wedge]

Okay will do this and just skip it for now! Thanks for all poking around 💙

[dapper yew]

Yeah that makes sense, I was being silly and put all my optimizations into web, and then didn't use the --release flag hehe
What about web-dev, is that no longer used? It was added to my Cargo.toml automatically by bevy cli I think

[limber wedge]

Thats not used yea. But it should not have been added by the cli we do not modify any files automatically

[small turret]

https://github.com/TheBevyFlock/bevy_cli/blob/7c2879bedacee35e509c4d27e48208115b29b385/bevy_lint/action.yml#L38-L60
Why not just rustup toolchain install 🤔
rustup is available by default for all runners IIRC

[pale viper]

That’s a good point! I don’t believe Rustup is available on self-hosted runners, though

[dapper yew]

Ah, I may be running an older bevy_cli

[rigid bluff]

Hello, for some reason using MinimalPlugins instead of DefaultPlugins makes the bevy run web client stuck in the loading screen, is this known ?

[limber wedge]

my guess is that its this

[pale viper]

Does MinimalPlugins include a renderer? If not, it might not be able to display anything, web or native

[vast vine]

I'm like 80% sure MinimalPlugins has no rendering. I'm not even sure it has windowing

[rocky oxide]

It does not

[rigid bluff]

Hello again, Would there be a way to have cargo run web send a new build after save ? Kinda like how many web frameworks do it ?

[near mist]

Like watch for changes and recompile?

[dapper yew]

Like a bevy serve web?

[limber wedge]

Like a cargo watch I assume

[foggy basin]

Right now there isn't, but we have an issue for it:
https://github.com/TheBevyFlock/bevy_cli/issues/245
I also want to add that we can hot reload assets on the web same as on native:
https://github.com/TheBevyFlock/bevy_cli/issues/189
And finally, integrating subsecond for hot reloading code would be amazing:
https://github.com/TheBevyFlock/bevy_cli/issues/451

[rigid bluff]

Hello again again, I seem to remember that the bevy_cli could allow for an automated upload to itch.io, though maybe i was misremembering and it was just a project template somewhere else, anyone know ?

[limber wedge]

hello fellow it was the 2d template

[rigid bluff]

Thanks i'll check that out, I'll try to copy and paste the parts I need into my project, would be cool if it could work with any project as a cli command

[near mist]

there is an issue for this: https://github.com/TheBevyFlock/bevy_cli/issues/350

[limber wedge]

https://github.com/TheBevyFlock/bevy_cli/pull/639 @pale viper yehhi ui test pass! They were really helpful on zulip thanks for the hints

[pale viper]

Awesome, glad to see the Clippy team helped out :)

[limber wedge]

A gh task that runs the linter on the bevy engine and checks that it does not ice would be cool to have. Could only run on main but it lets us find them easier until the linter is actually used in the engine ci

[pale viper]

Yup, after seeing the ICE issue you just opened, this would definitely be nice

[pale viper]

@limber wedge right now missing_trait_impls is only enforced for components. In #344 I mentioned extending its behavior to work on schedule labels as well, and @rocky oxide mentioned making the lint general over all unit types

Should we rename and clarify missing_trait_impls to just work on components, add support for schedule labels too, or expand it to work on all unit structs?

[limber wedge]

Oh right hahaha i was so locked in on components. I think changing it to work for all unit structs is the best outcome no?

Its the biggest change for the lint but its the desired result so i think we should go with that and maybe rename the lint to: missing_trait_impl_for_unit_struct

[pale viper]

I agree with you, though I’d like to wordsmith the name a little to make it shorter

Maybe…

• missing_trait_for_unit_struct
• unit_struct_missing_trait
• unit_type_missing_trait

[limber wedge]

i like missing_trait_for_unit_struct

[pale viper]

A fix for the ICE on Bevy main is up, check it out: https://github.com/TheBevyFlock/bevy_cli/pull/659

The change was simpler than I thought! I simply allowed unit_in_bundle to check projected types (T::AssociatedType: Bundle) along with normal generic parameters (T: Bundle)

I also added a regression test, so this bug shouldn't come back in the future :)

[limber wedge]

Yeei! Will have a look tomorrow

[kindred island]

Hi everyone! Is there a reason the default index.html doesn't make the canvas full-screen, like in https://bevy.org/learn/migration-guides/0-12-to-0-13/#remove-canvasparentresizeplugin ? I feel like the default behaviour should be for the canvas to fill the browser window. If people agree, I'm happy to make a pull request to add this

[foggy basin]

Is it sufficient to configure this on the CSS side or does it also require rust side changes (in the Bevy app)?
If it works through just that I'd personally be very happy to add this