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