feat(cli): add --no-run option to test

[benedikt-schaber]

cargo test provides the --no-run option, which can be quite useful, especially in things like CI. This PR adds this option to the test command as well:

It is documented in the help command like this:

Usage: cargo-leptos test [OPTIONS]

Options:
  -r, --release                          Build artifacts in release mode, with optimizations
  -P, --precompress                      Precompress static assets with gzip and brotli. Applies to release builds only
      --hot-reload                       Turn on partial hot-reloading. Requires rust nightly [beta]
  -p, --project <PROJECT>                Which project to use, from a list of projects defined in a workspace
      --features <FEATURES>              The features to use when compiling all targets
      --lib-features <LIB_FEATURES>      The features to use when compiling the lib target
      --lib-cargo-args <LIB_CARGO_ARGS>  The cargo flags to pass to cargo when compiling the lib target
      --bin-features <BIN_FEATURES>      The features to use when compiling the bin target
      --bin-cargo-args <BIN_CARGO_ARGS>  The cargo flags to pass to cargo when compiling the bin target
      --wasm-debug                       Include debug information in Wasm output. Includes source maps and DWARF debug info
  -v...                                  Verbosity (none: info, errors & warnings, -v: verbose, -vv: very verbose)
  -c, --clear                            Clear the terminal before rebuilding
      --js-minify <JS_MINIFY>            Minify javascript assets with swc. Applies to release builds only [default: true] [possible values: true, false]
      --split                            Split WASM binary based on #[lazy] macros
      --frontend-only                    Only build the frontend
      --server-only                      Only build the server
  -h, --help                             Print help

Test-specific Options:
      --no-run  Do not run the tests, only build them

Currently I think this is a breaking change on the library level. I did not know, how leptos handles this, but I can just wrap the old calls to make it non-breaking.

[gbj]

The feature itself seems reasonable to me. The way I usually handle this category of breaking change library-wise (i.e., adding an optional argument that has a sensible default value) is to create a second function with the additional argument, and then keeping the signature of the current function as is but calling out to the other function

pub async fn test_all(conf: &Config, test_opts: &TestSpecificOpts) -> Result<()> {
    test_all_with_options(&Default::default())
}

pub async fn test_all_with_options(conf: &Config, test_opts: &TestSpecificOpts) -> Result<()> {

[benedikt-schaber]

Thanks for reviewing my draft, I really appreciate it!

Nice, that is what I meant with wrapping, will update the PR tomorrow and remove the draft status.

[benedikt-schaber]

@gbj

Wrapped the compile commands so that they are now non-breaking. However, the change to src/config/cli.rs Commands remains breaking, if I understand that correctly. However, so is adding any new arg to Opts since it is not #[non_exhaustive], so cargo-leptos has done this repeatedly, if I understand correctly.

I would have to refactor cargo-leptos a bit to make it possible to actually stick to SemVer when updating the opts. I think that would be something for 0.4 also with a check in CI then.

[gbj]

I think that's fair. Using cargo-leptos as a lib is such a niche use case that we have not paid any attention to semver for it in the past. We probably should but I don't think it needs to block this change.