cargo-generate icon indicating copy to clipboard operation
cargo-generate copied to clipboard

Format resulting code

Open SergioGasquez opened this issue 3 years ago • 8 comments

Hi! Would it be possible to add a mechanism that formats (with rustfmt) the generated code? We are currently working on https://github.com/esp-rs/esp-template and we face the following:

  • If we add a RHAI post-script that runs cargo fmt, we have some issue as we generate the template in some CI and Dockerfiles that do not have the rustfmt component installed
  • We could try to solve it with withespace control, but since we have several combinations, it can be very tedious, and we would have to invest a lot of time every time we update the main.rs

SergioGasquez avatar Feb 23 '23 13:02 SergioGasquez

Sounds like a reasonable idea.

I guess adding an optional cli argument that would trigger rustfmt as a post script, would not be enough right?

I assume you as the template author would like to be in charge of controlling that rustfmt runs or not, right?

sassman avatar Feb 23 '23 14:02 sassman

I guess adding an optional cli argument that would trigger rustfmt as a post script, would not be enough right?

That could be an option

I assume you as the template author would like to be in charge of controlling that rustfmt runs or not, right?

Maybe not, why not format all the resulting code? Maybe have a cli argument to opt-out but, by default, I think it's a good thing that the resulting code is properly formatted, just my 2 cents.

SergioGasquez avatar Feb 23 '23 14:02 SergioGasquez

I like this :-)

I like the idea as a 'opt-in' most though, but at the same time, I'd suggest that the template itself could opt-in by specifying it in the cargo-generate.toml file.

Also, I would make it so that cargo-generate would only emit a warning in case the formatting fails!

taurr avatar Feb 23 '23 19:02 taurr

I'd suggest that the template itself could opt-in by specifying it in the cargo-generate.toml file.

I didn't think of it this way, but I really like this idea!

SergioGasquez avatar Feb 23 '23 19:02 SergioGasquez

as an extra bonus, using cargo-generate.toml to opt-in, allows the user to opt-in by default if so inclined - just opt-in using the global settings file.

taurr avatar Feb 23 '23 19:02 taurr

I'm thinking of providing some sort of cargo-generated provided "post-processors" that one can then select by name in their template config / or own config.

For example a post processor for "cargo build" or "cargo fmt" where the command and execution logic is provided by cargo-generate and the template author can specify the list of post processors they want to opt in.

The User executing this very template should be prompted if they also want to run this post processing step. This way the end user can opt out interactively. For running without a user (CI), there should be a --yes-to-all | --no-to-all argument that would opt-in/out to all optional steps.

sassman avatar Sep 04 '23 07:09 sassman

Hi! Is there any progress or update regarding this feature?

SergioGasquez avatar Jan 11 '24 08:01 SergioGasquez

Is there any progress or update regarding this feature?

The work on this feature as drafted above did not yet start. If it's a pressing need of yours, feel free to draft a PR that we can iterate on.

sassman avatar Jan 11 '24 12:01 sassman