(bonus points if there is a way to include class imports in that)

I understand that it would be a bad idea in general - warning on everyone who has ring via ring/ring is a bit much - but i'm thinking of it with respect to things like clojure.tools.logging where even if you like something like pedestal.log its hard to prevent the other require from being suggested and just messing it up

How would you determine the namespaces on your dependencies list?

I guess you would need to know what files came from what dependency + your list of "top" dependencies

which is information I wouldn't be surprised if its lost

i really like this idea though

I guess you'd have to parse through JAR files and look for Clojure/Script source files... plus handle the AOT-compiled Clojure core libs to deduce namespaces from class names...

This feels like a #lsp lint given that clj-kondo tries to stay single-file

Like how it adds the “unused public var” lint

(I can definitely see the potential benefits, to prevent you accidentally depending on something (via require) that happens to come in transitively now but might not later on)

It's an interesting idea, but a few adjustments: clj-kondo isn't "single file", it does keep track of var information from all the files that it has seen, such that it can deliver arity and type errors, but: clj-kondo doesn't really do anything to decide what is your "project". you just throw code at it and it keeps information about it around in .clj-kondo/.cache. clojure-lsp will automatically read your deps.edn etc, I guess it could figure out which namespace came from which jar file and then backtrack this to deps.edn, etc. so yeah, the more logical place for this would probably be clojure-lsp. There is some added complexity to track which deps are in scope concerning aliases and classpath commands, etc. If you have a custom classpath command you can't easily know which deps were directly declared related to that