`concurrently` alternative? (competing with a `package.json` dev experience)

I am here because what I just did feels wrong, and I'm tattling (on myself) to you for not knowing a better way. I added a package.json to my rust repo just to get a dev-tooling experience that is documented/easy:

{
  "scripts": {
    "start": "npx concurrently -n watch:  \"npm:watch-*\"",
    "watch-rust": "RUST_LOG=debug cargo watch -x run --ignore public",
    "watch-tailwind": "npx tailwindcss -i public/tailwind.css --config public/tailwind.config.js -o public/styles.css --watch"
  }
}

With this file, my README can just say:

Run npm start and then open your browser. It will pick up backend/html/CSS changes and recompile for you.

The crutch here feels like concurrently -- I want two processes watching their own files/directories for changes and running commands, so the user just has to refresh their browser and pick up new code. Is there an equivalent to concurrently in a rust package? Does anyone know of a good replacement that I can document as an easy way to get started on my repo?

in case I lost you, maybe this screenshot of the npm start results helps show what I'm trying to get (without a package.json):

You can run multiple commands one after the other with cargo watch.

When I'm working on some sort of server, I'll typically do something like this:

$ cargo watch --clear \
    -x "check --workspace" \
    -x "test --workspace" \
    -x "doc --workspace --document-private-items" \
    -x "run"

Technically, the server will go down while your code is being checked, tested, and documented, but that only takes about 3 seconds on my computer with the way I've set up my crates.

3 Likes

Thanks will give it another shot, but I'll reiterate what cargo watch felt like it was missing -- you have one ignore shared by all your cargo commands right? My two commands care about separate files. I don't need to recompile rust if only styles change, and vice versa.

The rust ecosystem is currently pretty weak dealing with the sorts of things npm scripts are used for unfortunately.

Your current best bet for that sort of thing I think is to add a scripts internal crate to your workspace, then add an alias to .cargo/config.toml that calls cargo run -p scripts [...args]. Then make this scripts crate call back into cargo or whatever, with whatever behavior you want. It's a lot more work, but a lot more flexible.

1 Like

Update: I don't know why I didn't look for a crate called the exact same name :smile: It looks like concurrently is a crate that does exactly what I need, complete with a .toml file users can examine. GitHub - tqwewe/concurrently: Run multiple processes concurrently.

I discovered that because I had started on my own version that is pretty similar. I got the basic idea working and then went to publish it as concurrently :joy_cat:

2 Likes

The tradeoff with cargo install binaries is, of course, they aren't automatically understaffed l installed and can't have different versions for different projects. It really annoys me in general.

I'll probably keep using the concurrently crate, but noticed it relies on tokio and a bunch of other stuff. Just in case my shitty 50-line thing is a tiny competitor, I pushed it to github and might publish it to crates at some point: GitHub - jakswa/rouse: built this before I knew the `concurrently` crate existed

it's now a crate, too: https://crates.io/crates/rouse