The current project discovery logic of kondo fails in edge cases related to assumptions made during the initial implementation.

• Directories represent at most one project type
• Projects cannot "nest" in the filesystem
• Users want to look for all types of projects at all times (no filtering)

While the assumptions work for the vast majority of users it would be nice to not be bound by them. By removing them from the code the project will support more users and scenarios.

Summary of edge cases

Users with a "root" directory that is being identified as a project, eg #29.

Projects with "sub-modules", eg #55 or tauri projects.

Directories that are more than a single project, eg a Cargo project that is also a Node project containing both Cargo.toml and package.json.

"Auxiliary projects" such as direnv raised in #101 that would almost always accompany a "regular" project in a directory, and may be too noisy to surface regularly.

Miscellaneous project structures that should be supported

Various Python project configurations, see #105 & #108.

Unity projects will have nested Node projects that should be ignored.

Rust workspace projects should ignore sub-crates that are in the workspace, but not ignore subdirectories that are not in the workspace.

Decide on if/how to handle git ignore.

Features that affect implementation

• Option to filter search to certain project types
• "Dry run" aka "listing" the directories
• Support for 3rd party "clean" commands like Cargo clean/Makefile clean Defer to 3rd party for removing artifacts #122
• To support "remembering" decision about using 3rd party "clean" or not (see above) kondo would need to store the users preferences on disk

Progress

Work is being done in https://github.com/tbillington/kondo/tree/discovery-rework.