Run on an entire project in a single command

[aheber]

It would be great if I could have a single execution that could process many files at once. Probably aiming at a directory path and discovering all compatible files (based on file suffix; probably apex,apexc,trigger,cls) and it would attempt to format each of them in turn, including per-file processing time and optionally writing back to the file.

I would expect the configuration TOML file to allow configurations for this process, such as a series of GLOB patterns for files that should be ignored maybe changing the file suffixes that are included. Maybe two glob arrays, one for include and another for exclude. Exclude winning if a file matches both.

[xixiaofinland]

As a human, I imagine myself using this feature in a new cloned project. Do we really want the TOML file to control what files to be formated and what not? or is this to be used in CI/CD?

What are the other use cases for this feature and how important is it?

[aheber]

I see the following general use cases.

1. I'm editing a file in my IDE and I wan't to configure it to manually or automatically reformat the file, often as a result of saving the file.
2. I am adopting this as my new formatter of choice, I expect to be able to reformat my entire project to a new baseline.
   (In my case, I want to do this but only to see the formatting differences across the codebase, not to commit yet, same process though)
3. Running in CI, I want to be able to have a step that validates that either all qualified files in the code base, or a list of files (probably files modified as part of the PR) wouldn't change if sent through the formatter again. (I wouldn't use the --write flag here but something similar to Prettier's --check flag, not really in scope for this issue but the bulk targeting seems like a pre-cursor to a check behavior, then I can ask for a --check flag 😉)

Where the TOML file comes into play is the "qualified" files part. If I were working on a project with node_modules I wouldn't expect a project-wide format to reach into that folder. I would like to aim and scope it, includes and well as exclude patterns.

Apex doesn't really do dependencies the same but I might want to exclude imported library files (maybe I'm working with FFLLIB or similar) and I never want afmt to reformat those files under any condition because even though I have to have them in my project they aren't really "owned" by this project and I want them to stay true to source, I also don't want them to be considered if we're evaluated the "formattedness" of the repo, no reason to penalize me for it. (The CI step above)

There are probably a few other cases, or more sub-cases to each of these.

Importance: I think being able to mass-reformat a codebase would be important for some. I've seen entire repos with one big commit for a new baseline formatting because they didn't want to see the changes included in future PRs as noise. For me, evaluating afmt I really want to apply it to a large set of files. I could always script the action, and if necessary I will for evaluation.

I don't think the TOML settings are as important to me, not to say I don't want it, but Apex has fewer "don't touch me" files than many other project types, I think the absence of configuration for project-wide scope is less of a problem but still maybe a 1.0 feature?

[aheber]

I went and took the script from your battle tests so I could process an entire project. That helped me to do a better review on the formatted output.

find .  -type f \( -name "*.cls" -o -name "*.trigger" \) -print | while read -r FILE; do
    /path/to/afmt-v0.0.12-aarch64-apple-darwin/afmt --write --file "$FILE"
done

I suspect it would be faster by a large margin if it were contained in single binary execution instead of starting and stopping each time.

[xixiaofinland]

I went and took the script from your battle tests so I could process an entire project. That helped me to do a better review on the formatted output.

find .  -type f \( -name "*.cls" -o -name "*.trigger" \) -print | while read -r FILE; do
    /path/to/afmt-v0.0.12-aarch64-apple-darwin/afmt --write --file "$FILE"
done

I suspect it would be faster by a large margin if it were contained in single binary execution instead of starting and stopping each time.

ahha, good job! Tools such as GNU parallel can easily multi-threading, or I could have a built-in feature in terms of formatting multiple files.

[xixiaofinland]

I see the following general use cases.

Thanks for sharing your thoughts & experience!

I probably have to focus on covering up the percentages in Project progress to get a well-rounded formatting tool before looking into the other accessory features.

It'd be nice to have a 2nd person to handle these in parallel, but I dont 😃 .

[aheber]

I hope I don't sound demanding. I'm very excited and grateful for your efforts here. There is no timeline on these, just filling the backlog if you will. I'm hoping that after I take a first review pass I can find some time to learn Rust and be able to contribute.

I'll let you know if I can get there and ask for some easy first issues :)

[xixiaofinland]

I hope I don't sound demanding. I'm very excited and grateful for your efforts here. There is no timeline on these, just filling the backlog if you will. I'm hoping that after I take a first review pass I can find some time to learn Rust and be able to contribute.

I'll let you know if I can get there and ask for some easy first issues :)

no, not at all. This is all important in this project and I appreciate you already consider and put thoughts on them.
Hopefully once the foundation is in place, other ones who are interested in this project can chip in :).

You have many great IT skills under the belt already, do things you enjoy if learning Rust is it 👍