Fork me on GitHub

I think I found one more potemkin corner case that I think we should consider on fixing it on clj-kondo 馃У


you can pass the first arg as the alias of the namespace and then the symbols


I found that a lot of things doesn't work on metabase because this issue


it should not be hard to support it I think


not sure though how to get the namespaces from the alias on clj-kondo code at that time


ah right so an alias instead of the full namepace right?


Also, it's possible to pass multiple vectors, but I think kondo is handling those already


ok, I'll take a look


@UKFSJSM38 should be fixed on master


oh that was fast :)


thanks, I'll will try




it worked! thank you! FYI @U11BV7MTK this should help with a lot of false positives on metabase , probably the rest is just macros that should be configured on clj-kondo side with lint-as and custom hooks :)


I'll include this clj-kondo bump on the next clojure-lsp release, thanks for the help @U04V15CAJ

馃憤 2

One more potemkin issue 馃槄 now related to kondo configuration 馃У


using the metabase as example again, I found a issue related to custom configuration like :lint-as for macros that are being used by potemkin


For example: metabase has dataset macro that I want to lint-as def . I added this to the .clj-kondo/config.edn :

{:lint-as { clojure.core/def}}
but that doesn't seems to work for the usages that use potemkin under the hood, for example This only works if I change the lint-as to the namespace that import the vars with potemkin like:
{:lint-as {metabase.test/dataset clojure.core/def}}


The user could add both namespaces to the lint-as is just that seems something clj-kondo could be smart and already check for the config for that imported potemkin var, right? Also, the same happens for hooks configuration


Sorry for bringing a lot of bugs, is just that I found metabase a good project to find/test LSP and see what doesn't work/could be improved :)


I agree this would be clever but this is a little bit complicated


how many macros is this about


we need to read the cache in an earlier phase to support this so it's not a trivial change


I added a TODO test: 0ae0e51158570d3c94be7c0c7b16c0c8cc593ecb You're welcome to make an issue about this but I don't consider this high priority for now (weighing the complexity vs how much effort it is to configure this)


Sure, that's fair, I only found 3 macros until now in the metabase that fall into this issue, but I agree this is no high priority


FWIW, I wrap a lot of library macros and functions this way (the indirection is useful if you want to augment or modify the original behavior systematically throughout your application) and sometimes end up adding both the wrapper and the original macro to clj-kondo. It's not pretty, but it has not been a deal-breaker so far.


^ I don't think this is inherently related to potemkin; but I may be wrong and some of my config linters are no longer necessary.


I'm not sure what you meant by the last sentence: you no longer need config which you needed before?


{ clojure.core/def
 metabase.test/dataset clojure.core/def}}
^ I was thinking that ideally one of these would be enough, and the other could be inferred.


yes, that was what this discussion was about.


Yep, I wanted to just add a datapoint that I come across this problem in my own projects, it'd be nice if it were fixed, but it's not something I consider a very thorny issue that is a pain to deal with it. If that was not obvious, sorry for adding to the noise. :)


thanks for the input. it requires an architectural change in clj-kondo, it might be fixed one day, welcome to make issues, but low priority for now


I wonder if would be useful to have a config to make clj-kondo clear if two things should be treated the same, but this is already what :lint-as is for more or less ;)