In certain pipelines, it is convenient to use cargo-leptos to build the lib target and associated files only. This can be done currently by re-implementing the functionality cargo-leptos provides manually, but that may require parsing the project's Cargo.toml, and it certainly requires more knowledge of the build process than is otherwise required to successfully use cargo-leptos.
An example where this is especially useful is a deploy pipeline for an AWS Lambda function. The server binary destined for the function must, among other things, target a particular architecture. cargo-lambda makes this very easy to achieve. Of course, the lib target and associated files do not require anything different, so they can be built with cargo-leptos as normal. Here's what this might look like currently:
My implementation is rather quick and dirty. I wanted to avoid adding a flag to all the subcommands when it only makes sense for build. Duplicating a large struct only to change one member is not ideal though. If there's a better approach for this feature, I'm all ears! I also totally understand if this feature isn't all that appropriate at the end of the day.
It may also make more sense to provide mutually exclusive flags (or an option of some sort) so either target can be skipped.
Utility
In certain pipelines, it is convenient to use
cargo-leptos
to build the lib target and associated files only. This can be done currently by re-implementing the functionalitycargo-leptos
provides manually, but that may require parsing the project'sCargo.toml
, and it certainly requires more knowledge of the build process than is otherwise required to successfully usecargo-leptos
.An example where this is especially useful is a deploy pipeline for an AWS Lambda function. The server binary destined for the function must, among other things, target a particular architecture.
cargo-lambda
makes this very easy to achieve. Of course, the lib target and associated files do not require anything different, so they can be built withcargo-leptos
as normal. Here's what this might look like currently:In this sequence, the bin target is built twice. With a
--bin-skip
flag, it would only be built once:Implementation
My implementation is rather quick and dirty. I wanted to avoid adding a flag to all the subcommands when it only makes sense for
build
. Duplicating a large struct only to change one member is not ideal though. If there's a better approach for this feature, I'm all ears! I also totally understand if this feature isn't all that appropriate at the end of the day.It may also make more sense to provide mutually exclusive flags (or an option of some sort) so either target can be skipped.