Fork me on GitHub
Noah Bogart01:04:01

Here’s a silly related idea that I'm strangely intrigued by. How would you feel about a style lint that checks's_laws? So, nested ands and ors flagging a warning if they could be reduced/combined (with the error recommending the reduction)

Noah Bogart13:04:12

If I write a hook for a core function, it won't overwrite built-in lints for the function, right? I only have experience writing hooks for custom functions so I’m not sure how these things work together


@nbtheduke You can build a hook for a core function and return nil in the hook, then the core linter will still run

👍 1

Quick question: are there good reasons for or against adding .clj-kondo to .gitignore? I currently don’t share clj-kondo config in my projects, but I just realised I don’t understand why I don’t share this config.


I think sharing it is a way to communicate what you expect from code added to the repo


like, you expect required namespaces sorted etc


Ya that's what I'm thinking, it's better to share it.


I normally add .clj-kondo/*/ to gitignore, that makes the cache and any copied configs not be checked in


In my projects I now have:



I'm curious: would you not share copied configs? For example, our project uses slingshot which has custom config. If I was to exclude that then all other developers would have to manually set up the custom config themselves to clear those errors.


I've been debating that, but since an early step in our CI is to analyze deps with --copy-configs and we usually also have that as a bb or just command in every repo, I don't really see the point


if a dev uses kondo, they'll know how to lint deps with copy configs


and this way we save some churn that might happen when an updated dependency brings in a new config


Ok, makes sense. I haven't added code analysis to our CI pipeline yet (still early stages), and I can see how that would help plug that particular gap in a different way. Thanks for the insight.


I have seen @borkdude recommend checking these in though, so I'm a bit on the fence about it


All files in .clj-kondo I check into source control except .cache


The reason is that everyone working on the same code, including CI, gets to see the same config


Do you have a step to check that imported configs are in sync between the .clj-kondo folder vs their publishing libraries?


Hi @borkdude, I've recently joined metabase and I think this is not possible, but I wanted to run it by you. As it stands, functions marked with :hydrate or :batched-hydrate metadata seem to be unused but are, in fact, invoked by calls to toucan.hydrate/hydrate. On the flip side, from calls to hydrate finding the function definition can be difficult. Registration: - - Usage: - - I would like to: 1) hook into clojure.core/defn to reg-keyword! the hydration key. - I'm not sure what would happen if I tried to hook defn, I suspect bad, recursive things? 2) hook into toucan.hydrate/hydrate to register a usage of the defn var (`add-member-counts & members` in the example) based on the keyword used. - I think ns-analysis is insufficient as I do not know in which namespaces the functions with :hydrate are defined. It'd be nice if it was possible to create hooks for these without code changes, but I suspect I will need something like re-frame's reg-sub to wrap the registration and give kondo a seam?


> I'm not sure what would happen if I tried to hook defn, I suspect bad, recursive things? This is possible. It's currently not possible to use more than one hook per function though, there can be only one (again, currently). > toucan.hydrate/hydrate If the name of the keyword uniquely defines the name of the var, you could expand that call into an explicit call which makes the var usage visible to clj-kondo.


I thought about this, but unfortunately it's common for them to differ. The 2nd registration example shows var add-member-counts is registered as the :member_count key


@snoe There is now a new :context option, you can add to keywords:

(assoc-in node [:context :metabase/hydrate true]) 
which will appear in the analysis output


If I hook hydrate and grab the keyword node, would I be able to look up the context added from other analysis? That would be pretty powerful for hooks. Not sure if it'll work in this case as the registry is determined at runtime, so the call site might be analyzed before the defn.


That's not how it works. The keyword + context ends up as is in the analysis. It doesn't mean that all other identical keywords get that context added, it's just a way to add extra info to the analysis output


Ok, thats what I suspected, but if it did work that way would it could be pretty powerful; I think I could probably use it to solve this :) handwaving It would probably require a type of post-analysis hook that could only register findings/keyword/var/var-usage but have access to :context values for a given keyword/symbol.


but if you would use namespaced keywords throughout, you would be able to find keyword references unambiguously - or maybe stepping away from keyword indirections is an even better solution

☝️ 1

aye, was curious how far I can get without code changes, but that's my intuition at all.


Thanks for the thoughts, appreciated!