kondo
kondo copied to clipboard
Keep looking inside project
For example, the target
dir at <rust_project>/examples/<example>/target
is ignored, only <rust_project>/target
is removed.
And if all examples were built for test purposes, the sum of those targets can often exceed the crate's main target
I run into that even on this project :) the kondo-ui
subdirectory is not part of the workspace so it has it's own target directory, which is skipped because it's inside a project.
The code causing this is here https://github.com/tbillington/kondo/blob/7a549b64a300bc00764e26e1f4987aa440d49212/kondo-lib/src/lib.rs#L224-L225 Essentially, stop recursing if a project is found. This is helpful in nodejs projects because node_modules has projects within, and it's not useful to work with those. It also gave a massive speed boost because of how much work it could skip.
Perhaps this decision should be on a project type basis.
Or a project type basis. With node_modules
you either want to delete the whole tree, including transient dependencies, or you want to keep all of it.
But with Rust target
, the other target
s are not under the top target
. In fact both specifically examples
and any other workspace/non-workspace nested projects are whole projects, precisely because they are source projects and not just published dependencies.
So, should it ask for each nested project, or just once for the topmost project and apply that ruling to all nested projects? 🤔
Also sometimes you have node_modules
in Rust projects and Rust target
in npm module projects...
That's a good point, I hadn't considered directories that are more than one type of project, eg cargo and node project. Hmm... I'll have to think on that, also how to recurse directories that are not artifacts of the current project, the implementation now might make that a little tricky.
Still, at least looking at just Rust and nodejs, it seems like differentiating between:
- artifact directories (delete, never enter)
- literally everything else (don't delete, recurse)
should be sufficient?
So:
- get directory listing (actually collect to memory)~~, while looking for marker files that signify a project~~. You can actually collect into two
Vec
s byDirEntry::file_type()
which unlikemetadata()
is said not to involve additional syscalls. - look through directory listing, looking for marker files and immediately mark the corresponding artifacts for "deletion".
- recurse on directories that have not been marked.
That makes sense. I'll think through it. I think this might also be a good opportunity to add integration tests for the project, and model these situations.