Required version in Trunk.toml?

[ctron]

I was considering a way to ensure that a trunk version actually supports the configuration options of a project.

An easy approach to this could be to have a required_version in the Trunk.toml file. Assuming there is one of course. However, that could allow for an easy check if the project is compatible with the trunk version.

On the other side, it might make things more complicated? Any thoughts?

[simbleau]

At the same time we do this, I think we also inform users to upgrade versions consistently.

"Hey, looks like you're on Trunk 0.17.2 - The current version is 0.17.4. To upgrade, please type cargo install trunk."

[stefnotch]

IMO the ideal way would be if Cargo had support for custom tasks[1], and Trunk were a dependency like everything else. Then Trunk could just live in the Cargo.toml file, add a bunch of commands and it'd work as expected.

[1] custom tasks like https://github.com/sagiegurari/cargo-make or https://github.com/matklad/cargo-xtask or maybe https://rust-lang.github.io/rfcs/3424-cargo-script.html

[ctron]

@stefnotch True, but I think extending cargo that way is out of the scope of this repository.

[stefnotch]

@ctron Yeah, it's probably quite a lot of effort at the moment. It might become easier in the future as cargo develops.

I personally am worried about how one would best manage multiple trunk versions on one machine. If I have two projects that depend on Trunk, but one of them still depends on an older, incompatible version of Trunk, how do I best deal with that?
There are a few web projects that basically have the same issue (e.g. Node.js, or the Angular CLI).

Hence my wish for

• The global trunk binary is just a very simplistic task runner (similar to cargo-xtask). (Alternative: Cargo script, once it's available)
• The actual trunk WASM web application bundler is a dev-dependency of my projects. Nice and locally scoped, and I always have the correct Trunk version

Hopefully that explanation and the reasoning makes sense?

[ctron]

Makes total sense, and good to know about that use case.

I am worried about the case where be come up with breaking changes, and that results in "doesn't work" kind of errors ports, just because the version doesn't match.

I think a good first step would be to make the user aware of that situation. And that could be achieved by requiring a specific version of trunk, in one form or another.

[stefnotch]

Another variant that'd be amazing would be rust-lang/cargo#2267

[ctron]

Another variant that'd be amazing would be rust-lang/cargo#2267

Absolutely. To but my understanding, that is not available today. And requires some work in cargo first.

[ctron]

Released with trunk 0.19.0.

[stefnotch]

@ctron There is actually one way of doing custom cargo commands at the moment. It's a lot more verbose than one would like, but I figured that it'd be interesting nonetheless. Especially since it avoids versioning issues by making Trunk a proper dependency.

https://github.com/rukai/cargo-run-wasm

[ctron]

I guess that could be achieved by making Trunk a lib too (which might be great addition anyway) and then having a simple (or similar):

fn main() {
  Trunk::run("./Trunk.toml");
}

And that would work with wasm_bindgen. But how about sass, tailwind, … I think that would get quite tricky, quite fast.

[stefnotch]

@ctron I figured you might find this interesting leptos-rs/cargo-leptos#399 (comment)

If that's interesting enough, I can open a new issue to properly track this.

[ctron]

@stefnotch I can't really follow what the ask is. In general, everything that you think makes trunk better is worth an issue.