Fork me on GitHub
#clj-kondo
<
2022-02-16
>
lread13:02:40

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?

borkdude13:02:33

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

lread13:02:16

Ha! Coolio, I will make a git issue.

imre13:02:53

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.

borkdude13:02:57

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

borkdude13:02:11

@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

seancorfield13:02:40

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

seancorfield13:02:49

(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?)

borkdude13:02:00

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

lread13:02:54

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

borkdude13:02:00

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

lread13:02:40

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

lread13:02:03

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

๐Ÿ™ 1
seancorfield14:02:02

If a library is archived on GH, it's not going to get updates to add deprecation metadata ๐Ÿ˜‰

borkdude14:02:43

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

borkdude14:02:59

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

borkdude14:02:24

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

seancorfield14:02:47

Do you lint project.clj files?

seancorfield14:02:33

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

borkdude14:02:33

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

lread14:02:16

Mentioned antq might be an interesting partner in this crusade