Pin version of cargo-leptos

[stefnotch]

For my projects, I would like to have cargo-leptos behave more like a regular Rust dependency. This means

1. Specify its version in Cargo.toml, or a similar file.
2. Automatically have it installed, and accessible under some command. It is ok if the command ends up being a slightly longer cargo xtask leptos --help , or cargo leptos.rs --help

Number one would let me guarantee that every team member uses the same version of cargo-leptos, instead of "works on my machine". It also guarantees that the CI uses the correct version of cargo-leptos.

Number two means that onboarding new contributors is as frictionless as possible. Repeatedly having to tell people to install cargo-leptos (or trunk), and to keep it up-to-date, is a pain point for me.

And finally, if done well, I could juggle different projects that depend on different versions of cargo-leptos. Usually this happens when one project hasn't updated its dependencies just yet.

[huuff]

I understand this is not viable for everyone but I'd suggest giving nix a try for this. We use nix to pin and provide all dependencies for everyone and it works for all kinds of dependencies, not only rust/cargo-related.

[gbj]

It's not a Rust library crate, it's just an ordinary binary CLI tool, so I'm not sure there's a way to do what you're asking from cargo-leptos's end.

[stefnotch]

I understand this is not viable for everyone but I'd suggest giving nix a try for this. We use nix to pin and provide all dependencies for everyone and it works for all kinds of dependencies, not only rust/cargo-related.

That would be an amazing solution, if there were a straightforward option for Windows. As me and a lot of my collaborators are in the field of computer graphics, having Windows support is the expectation.
Yes, it's possible with the WSL, but having tried that: It's a significant hurdle. Significant enough to make manual installation attractive again.

[stefnotch]

It's not a Rust library crate, it's just an ordinary binary CLI tool, so I'm not sure there's a way to do what you're asking from cargo-leptos's end.

I'm suggesting using a cargo script named leptos.rs (or the xtask trick) with code along the lines of

#!/usr/bin/env cargo

//! ```cargo
//! [dependencies]
//! cargo-leptos = { version = "0.2.21" }
//! clap = "4.5.21"
//! tokio = "1.41.1"
//! ```

use cargo_leptos::{config::Cli, ext::anyhow::Result, run};
use clap::Parser;
use std::env;

#[tokio::main]
async fn main() -> Result<()> {
    let args = Cli::parse_from(&env::args().collect());
    run(args).await
}

// Ideally this setup would require even less code (e.g. by having cargo-leptos expose a helper function just for this)

Then I could drop that script into any of my projects and invoke it.
It does re-download and re-compile cargo-leptos for each project, but that is a very worthwhile trade-off in my view.

And from there I'd go a step further: Please make this the officially recommended option, especially once cargo-script stabilizes.

[Nutomic]

Ultimately this seems to concern the same issue described in leptos-rs/leptos#3186: Minor versions of wasm-bindgen are incompatible, so two people working on the same project with different versions of cargo-leptos will consistently run into problems.

A solution was also suggested there by @DanielleHuisman

I looked into the cargo-leptos pinning issue a bit more. The only reason the version mismatch exists is because cargo-leptos is compiled with wasm-bindgen-cli-support.

I was using Trunk and didn't experience any issues. Trunk is not compiled with wasm-bindgen-cli, but instead finds the appropriate version to use from Trunk.toml/Cargo.lock/Cargo.toml. It then downloads the right binary to a cache and calls the binary to build the bindings.

Using a similar approach in cargo-leptos would solve the pinning issue. If this sounds like an interesting solution, I'd be happy to make a PR for cargo-leptos.

[stefnotch]

I figured I'd put my money where my mouth is, and demonstrate that it's absolutely doable with the upcoming cargo-script.

Here is the trunk vanilla demo, tweaked to run with cargo-script.

drunk-demo.zip

To do that, I did the following

1. I turned Trunk into a library.
2. I wrote the script below
3. I started it with cargo +nightly -Zscript trunk.rs serve --open
4. It works.

Notably, at no point did I have to do cargo install trunk. Furthermore, I can actually pin the correct version of Trunk (not done in this example).

The cargo-leptos stuff should work analogously.

#!/usr/bin/env cargo +nightly -Zscript
---cargo
[package]
edition = "2024"
[dependencies]
trunk = { git = "https://github.com/stefnotch/trunk" }
tokio = { version = "1.42.0" }
---

/// Run with
/// cargo +nightly -Zscript trunk.rs serve --open 
/// 
/// Eventually we will be able to do 
/// cargo trunk.rs serve --open 
/// 
/// And in an even nicer future, we can do
/// ./trunk.rs serve --open 
#[tokio::main]
async fn main() {
    let a = trunk::run_cli().await;
    println!("{:?}", a);
}

(P.S. Currently Trunk needs extra dependencies on most Windows systems, thanks to OpenSSL and RustTLS demanding some extra dependencies outside of cargo.)

[stefnotch]

In case anyone finds this interesting: I opened an equivalent issue on the Trunk repository.
trunk-rs/trunk#924

[benwis]

This is an interesting idea, although I remain unsure if the trouble is worth it. It feels like binary package management is outside our scope, and there's definitely some complexity in managing the things we depend on. I'm going to close this for now but if you'd like to work on it you are welcome to

[stefnotch]

Sounds good.

The most relevant Rust issue for this seems to be rust-lang/cargo#2267 (comment)

If we had that, then my feature request would be straightforward to implement.