I don't like to do this kind of trivial traversal ourselves, given many tools like fd already satisfies this goal. We could extend diagnostics subcommand to accept multiple paths so it would be faster with fd --exec-batch (as in #126).

If it's possible, I would prefer discover all nix files using path reference traversal which is already in the code but not enabled yet. Though it may take more time to be fully implemented.

We could extend diagnostics subcommand to accept multiple paths so it would be faster with fd --exec-batch

It would still be limited by command-line argument size limits, and it would still be a lot clumsier to use than just traversing the directories natively. There's a reason (e.g.) cargo clippy doesn't make you list every Rust file in your project.

If it's possible, I would prefer discover all nix files using path reference traversal which is already in the code but not enabled yet. Though it may take more time to be fully implemented.

I'm not confident this is feasible or desirable. Paths can be constructed programmatically, so it's not easy to get a list of imported paths with static analysis. Functions like builtins.readDir (and nixpkgs' lib.packagesFromDirectoryRecursive) further complicate matters.

It's also fairly normal for users to import paths from a directory or flake manually, even if the default expressions don't invoke them. (Nixpkgs makes use of this in several places, for example.) For that reason, I'll want to lint all of the Nix code in my repo, even if it's not explicitly imported by another file.