This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-28
Channels
- # aleph (3)
- # babashka (66)
- # beginners (96)
- # calva (45)
- # clj-kondo (28)
- # clojure (30)
- # clojure-dev (2)
- # clojure-europe (20)
- # clojure-germany (22)
- # clojure-norway (4)
- # clojurescript (176)
- # clojutre (1)
- # cursive (23)
- # datalog (6)
- # datomic (7)
- # docker (3)
- # emacs (3)
- # exercism (4)
- # figwheel-main (5)
- # fulcro (8)
- # gratitude (9)
- # hyperfiddle (8)
- # introduce-yourself (2)
- # jobs (2)
- # malli (4)
- # membrane (3)
- # off-topic (17)
- # polylith (3)
- # portal (2)
- # re-frame (27)
- # reitit (3)
- # releases (1)
- # remote-jobs (1)
- # shadow-cljs (152)
- # spacemacs (8)
- # tools-deps (15)
- # vscode (1)
- # xtdb (24)
Here’s a silly related idea that I'm strangely intrigued by. How would you feel about a style lint that checks https://en.wikipedia.org/wiki/De_Morgan's_laws? So, nested and
s and or
s flagging a warning if they could be reduced/combined (with the error recommending the reduction)
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
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 normally add .clj-kondo/*/
to gitignore, that makes the cache and any copied configs not be checked in
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
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
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:
- https://github.com/metabase/metabase/blob/master/src/metabase/api/permissions.clj#L84
- https://github.com/metabase/metabase/blob/master/src/metabase/models/permissions_group.clj#L111
Usage:
- https://github.com/metabase/metabase/blob/master/src/metabase/api/permissions.clj#L109
- https://github.com/metabase/metabase/blob/master/src/metabase/api/permissions.clj#L116
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 outputIf 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