Fork me on GitHub

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 ๐Ÿ™‚


(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,


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


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


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

๐Ÿ™ 1

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?


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


Mentioned antq might be an interesting partner in this crusade