Defer to 3rd party for removing artifacts

[tbillington]

Some 3rd party project management tools include commands, or users add them by convention, that clean their workspace.

Eg Cargo will remove target, and users of Makefiles and other scripting tools may create their own "clean" command.

Should kondo defer to these tools?

I'm inclined to say yes, however there may be situations where kondo knows more about the artifacts than the specific tool. There also may be situations where the user has implemented a clean command that performs some specific actions that kondo can't reasonably mimic.

It's not obvious to me which path kondo should take. I am erring on the side of not depending on the 3rd party tools because:

• We don't have control over what they're doing
• They may have different behaviours between versions
• We don't know the semantics of "clean" that users have implemented, it may not mean the same thing we assume it to
  • For example, buck2 clean also kills the buck2 daemon

That being said, it does make sense to defer to tools like Cargos clean command, since it is the standard for projects of that nature.

[luiswirth]

Interesting. I'm surprised that this is not what kondo is already doing. I have assumed that it did! I'm in favor of deferring the cleaning to other commands, as this keeps the code of kondo smaller and doesn't duplicate this logic that is already implemented in another program (like cargo).

[tbillington]

While attractive, there are issues involved with using the 3rd party option off the top of my head.

• kondo would realistically need to shell out to them (as opposed to including/linking their code), which has it's own complexities
  • kondo must now know the API of many different 3rd party tools, what if the API/flags of the tool changes?
  • kondo now must manage running 3rd party processes and handling their failures
  • Misc things like what should the current working directory be set to when running the commands
  • The environment kondo runs is now much more significant. If kondo is shelling out it may not be obvious to the user, and if the user has different versions of a tool, or uses a meta tool like rustup or some kind of directory based environment tool like autoenv kondo may not find the tool or use the wrong tool/version.
• We don't know what they're doing
  • "Dry runs" are not viable anymore, as 3rd parties don't often expose the information
  • One of my goals is to have the user able to know/query what kondo does/will do (CLI option to print artifact dirs in plaintext #9), and it wouldn't be possible using 3rd parties
  • Calculating the artifact size and amount "cleaned/recovered" is now not reliable because there may be a mismatch between kondo's logic and 3rd party tools, and 3rd party tools in my experience don't allow querying for that information. It may be possible to "brute force" how much the 3rd party has cleaned by doing a before/after size comparison but that is extra work/overhead

We could separate the tools into two categories. Category A would be standard tools in the ecosystem, such as Cargo and it's clean command, and category B being more "convention" based like your Makefile example.

In my opinion category A is a stronger option than category B, but still suffers from the "shell out" issues raised above.

This is further complicated by projects possibly having both a category A option (Makefile/justfile) and a category B option (being a Cargo project) 😅

The "best" option would be to allow the user to specify their preferred choice for a given project. Choices being kondo built in, category A, category B. For UX it would be ideal to allow kondo to "remember" the decision for a given project or project type.

---

Thanks for your comment, responding to it helped me think through the above!

---

I'm surprised that this is not what kondo is already doing

That's interesting to know! My assumption has been that people would assume the opposite, so that's informative :)