Just an idea, not sure if it is a good one: I don't know how many times I've seen @seancorfield remind folks that clj-time is deprecated. I wonder if clj-kondo should/could warn on direct use of libraries that have been clearly documented as deprecated (except maybe not via :deprecated metadata). Some sort of ns list maybe?

@lee I think that's an excellent idea and I assume @seancorfield would agree

Ha! Coolio, I will make a git issue.

Would be a good idea to add some documentation to reported failures on those. For example a link to an official-like statement or warning etc.

libraries could include this in their own exported clj-kondo config, that seems like the most authoritative statement

@lee there is maybe already a related issue for deprecated namespaces. if a library as whole is deprecated, perhaps they can mark all of their API namespaces as deprecated and users would see it that way

Yes, I would love to see clj-time flagged as deprecated in code and in deps.edn (as both clj-time/clj-time and as just clj-time -- not sure whether clj-kondo canonicalizes libs?). depstar should also get flagged in deps.edn with a recommendation to use tools.build 🙂

(for the latter, you'd have to check for seancorfield/depstar, com.github.seancorfield/depstar, possibly io.github.seancorfield/depstar, and also com.healthfinch/depstar so I'm not sure how you'd want to handle that?)

well, doing it via the namespace metadata would be way easier, since that's what's clj-kondo is analyzing anyway and there would be no special rules inside clj-kondo needed for that

Oh I didn't realize clj-kondo did not already warn on deprecated nses, https://github.com/clj-kondo/clj-kondo/issues/1125.

(ns depstar
  {:deprecated "use tools.build instead"})
  ^ Namespace depstar is deprecated: use tools.build instead 

Thought: That would help folks not to use the latest version of depstar, but the deprecation applies to all versions of depstar.

true...

I think I'll raise the issue describing the problem, I'll link to the deprecated ns issue as related.

If a library is archived on GH, it's not going to get updates to add deprecation metadata 😉

ok, so adding out of band information to a built-in config seems the way to go then.

and I guess we could add out-of-band information about deprecated namespaces inside of those libs as well

while also supporting deprecated namespace data, so someone can add that information before archival

Do you lint project.clj files?

no

Just thinking that if you're going to start flagging libs in deps.edn you could also do that for project.clj 🙂

makes sense, since a lot of usage of those deprecated libs are still on project.clj

Here is the issue: https://github.com/clj-kondo/clj-kondo/issues/1591

Mentioned antq might be an interesting partner in this crusade