cargo fmt vs. leptosfmt

[qknight]

cargo fmt

cargo fmt only updates files in places which belong to my project while leptosfmt updates all files in the current directory, including the target folder.

Could leptosfmt somehow get the cargo fmt managed files and only work on these?

time cargo fmt
real    0m0.229s
user    0m0.204s
sys     0m0.009s

time leptosfmt .
real    0m11.845s
user    0m2.924s
sys     0m4.534s

I see these attempts in updateing all sorts of .rs files:

.direnv/flake-inputs/vvk51jcqaq7a2sqsyyvs1svpnif1b4r0-source/web-app/src/explorer/mod.rs
...
target/debug/build/markup5ever-f2d1eca314a070f5/out/generated.rs
...

So when I remove target and .direnv I get:

time leptosfmt .
real    0m1.853s
user    0m2.236s
sys     0m3.059s

Which is still long but much more managable.

update

Just found this discussion: https://stackoverflow.com/questions/60989162/how-to-list-a-projects-source-files-using-the-cargo-crate

[its-the-shrimp]

I've been inspired by leptosfmt to make a similar tool for Yew, yew-fmt, and the way I handled the issue of synchronisation with cargo fmt is by making yew-fmt copy the API of rustfmt and be a wrapper over it, i.e. by accepting the same keyword args, accepting not a directory, but individual files that are to be formatted, and calling rustfmt before any logic of its own. This allows for yew-fmt to be a drop-in replacement for rustfmt (to be dropped in as e.g. RUSTFMT=yew-fmt cargo fmt), and receive all the files that have to be formatted right from cargo by being invoked by it. Just dropping this here as an idea for a potential fix to this issue