:)

Unfortunately, I don't have anything helpful for you on the technical side. You should join the Gitter, though, if you have questions about JCoz: https://gitter.im/JCoz-profiler/community

@hcoles Here you go: https://github.com/Octogonapus/reproduce-pitest-problem I tested cloning it and running `./gradlew :dsl:pitest` to reproduce the problem.

I typically don't run `clean` before I build.

> building releases from tags sounds fine to me, any reason not to do it that way? Not really. I always do it that way.

The easiest way will be to release the entire app's folder, which can be downloaded and run like: ```sh /path/to/JuliaFormatter-0.22.10-x86_64-Linux/bin/JuliaFormatter [PATHS...] ``` We'll need to release an artifact for each...

If the vscode extension team wants to include this in their releases, they are welcome to, but I am just focused on getting artifacts published to the releases on this...

I will mention that this would make the extension's formatting faster for the first few runs, but slower overall as this involves invoking a separate binary, doing argument parsing, etc....

Ok, Comonicon could be a better option here. Though it needs at least one new feature; this cpu target needs to be customizable https://github.com/comonicon/Comonicon.jl/blob/master/src/builder/install.jl#L60. > I'm not sure it's legit...

@Roger-luo So if I understand [these docs](https://comonicon.org/stable/project/#project) correctly, the best way to approach this project is to create a JuliaFormatterCLI.jl project separate from this one. That project can release tarballs...

I recently had time to revisit the rewrite of this project. It currently lives in [this repo](https://github.com/Octogonapus/JuliaFormatterCLI). The proof of concept is implemented. I'll be refining it over the next...