This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-12-17
Channels
- # adventofcode (25)
- # announcements (2)
- # babashka (16)
- # babashka-sci-dev (16)
- # beginners (213)
- # calva (15)
- # clj-kondo (126)
- # clj-on-windows (1)
- # cljdoc (5)
- # cljfx (1)
- # cljs-dev (6)
- # clojure (230)
- # clojure-europe (38)
- # clojure-nl (3)
- # clojure-uk (3)
- # conjure (10)
- # core-async (15)
- # cursive (33)
- # fulcro (58)
- # hyperfiddle (4)
- # jobs-discuss (1)
- # kaocha (5)
- # lsp (46)
- # meander (3)
- # off-topic (30)
- # polylith (10)
- # portal (9)
- # re-frame (5)
- # reitit (7)
- # releases (2)
- # ring (17)
- # sci (8)
- # shadow-cljs (6)
- # specter (1)
- # sql (1)
- # testing (9)
- # tools-deps (4)
- # vim (12)
Hi, thanks for the big release, but there seems to be a problem with re-frames subscriptions. I built a minimal example for this:
(require '[re-frame.core :as rf])
(defn- show-id [subscription]
(let [id @(rf/subscribe subscription)]
[:h4 id]))
(defn- ids []
[show-id [:user/id]])
(rf/reg-sub
:user/id
(fn [db _]
(get-in db [:user :id])))
So there is the component ids
, which should show in this example some ids, doesn’t really matter. The subscription key [:user/id]
is provided via an argument. But clj-kondo says there is an unused binding:
src/main/schnaq/interface/user.cljs:56:17: warning: unused binding subscription
The error message points to line 3, where subscription
is the parameter of the component.
I filed an issue for this: https://github.com/clj-kondo/clj-kondo/issues/1504
Thanks for the issue, I'll take a look. /cc @U0508JT9N
hm… the problem could be that we don’t analyze the paramaters of the rf/subscribe
apart from the special code which tries to figure out the subs id. so ‘ordinary’ clj-kondo misses the usage of the subscription
local
@U0508JT9N This looks suspicious:
[subscription-id & subscription-params] (:children (first (next (:children expr))))
first next?when I change this to
[subscription-id & subscription-params] (next (:children expr))
then it works again@U1PCFQUR3 perhaps as a workaround you can use that syntax for now?
i don’t think we handle the case when the subs param vector is passed in as a local as in the above bugreport repro example
if you don't want to wait for the fix, I think it might be better if you passed the args to build the subscription instead of the subscription itself, so clj-kondo can see the keyword and static analysis improves by that as well, if in the future you want to find all references
but since it's already a subscription, I don't think you need to pass it through subscribe at all
Subscriptions can have arguments, which is why we pass the vector to respect the arguments. Sometimes the subscription key changes, but the provided data follows the same structure, which is why we provide the complete vector for re-frames subscription function
@U1PCFQUR3 Not sure if this is blocking anything, I'll wait for some more bug reports related to the new release and then will do a small release soon-ish
@borkdude today is an ironic day – I have been repsonsible for accidentally breaking 1000s of peoples builds on CircleCI over the years, but today you broke my build 😄
clj-kondo
is warning that our definition of random-uuid
is shadowing clojure.core/random-uuid
, and we have warnings treated as errors.
Also, thank you for the new version of kondo and all the word you do on it!
We have a leiningen project that uses Clojure 1.10, and when we run clj-kondo it’s outputting this:
[clj-kondo] Auto-loading config path: babashka/sci
[clj-kondo] Auto-loading config path: babashka/fs
src/workflows_conductor/entities/uuid.clj:7:1: warning: random-uuid already refers to #'clojure.core/random-uuid
linting took 2223ms, errors: 0, warnings: 1
our script to invoke it is:
#!/bin/bash -eo pipefail
# Turn off errexit as we want to continue and catch the error code ourselves
set +e
lein clj-kondo --lint src
ret_code_src=$?
echo
# For tests we allow private-call; otherwise use the same config as src
lein clj-kondo --config '{:linters {:private-call {:level :off}}}' --lint test
ret_code_test=$?
# Now fail the job if *either* of the src or test
# invocations returned a non-zero error code
[ "$ret_code_src" -eq 0 -a "$ret_code_test" -eq 0 ]
random-uuid
isn’t in clojure.core
1.10 right?
We’re going to add (:refer-clojure :exclude [random-uuid])
to our namespace
aha, that’s it!
Thanks!
@U0K592YDP sorry to raise this thread, but I’m seeing this behaviour as well and am not sure what is meant by “lint your dependencies”, could you share how you got around this?
We worked around this like this by adding the following:
;; With clojure 1.11 alpha, the (random-uuid) function is introduced.
;; We don't have this yet, so let's silence the warning.
;; We may want to consider replacing our custom function with the built-in
;; one if we upgrade clojure.
#_{:clj-kondo/ignore [:redefined-var]}
(defn random-uuid
"Returns a random type 4 universally unique identifier."
[]
(UUID/randomUUID))
Thanks!
apologies, my google-fu is failing me. how do i clj-kondo on an M1 Silicon mac?
on an M1 mac?
➜ bootstrap git:(master) ✗ brew install borkdude/brew/clj-kondo
Error: Cannot install in Homebrew on ARM processor in Intel default prefix (/usr/local)!
Perhaps this helps? https://apple.stackexchange.com/questions/408375/zsh-bad-cpu-type-in-executable/408379#408379
Yes, but you have the same error as I had. If homebrew wants to install in /usr/local, homebrew is trying to install x64 programs.
I had it misconfigured when I switched to an M1 mac, deinstalled it completely, installed it again and then it chose to install arm tools instead. Had it misconfigured, because I migrated via a time machine image from an x64 mac to an arm mac
softwareupdate --install-rosetta
arch -x86_64 brew install borkdude/brew/clj-kondo
this worked, thank you!
yes but now you have to add the prefix every time. Homebrew can directly prefer arm tools instead.
Actually I am not quite sure if this is really a good solution. In my opinion, you should install the arm-version of homebrew, which then automatically selects the arm-based tools instead.
thanks n2o, still in the first hours with the new machine 😅 you've given me enough to dig with, thanks!
I struggled several hours with it, because I do not want to specify the architecture on every installation 😅 A re-installation fixed it in the end. So that homebrew now prefers arm recipes over x64.
TIL: when running lein test
on the clj-kondo repo the user-level (`~/.config..` ) config is applied. depending on the settings, this will cause tests that assume default behaviour to fail. what do you guys do to avoid this?
@maximilian you can try to add a metadata value on :config-paths ^:replace []
in the default test config, this will make it ignore the home dir
well, it does make the test fail that’s supposed to check whether the config in $HOME
gets picked up, but that’s a good thing i guess 🙂
i’m wondering … what’s your setup for running tests locally without having to comment your personal settings?
This is my personal config:
{:linters {:unsorted-required-namespaces {:level :warning}
:used-underscored-binding {:level :warning}
#_#_:shadowed-var {:level :off #_warning
:include [name]
:suggest {name nom}}}}
I'm fine with making the above change and tweaking the default config for the home test
minimal example:
{:linters {:unused-binding {:exclude-destructured-keys-in-fn-args true
:exclude-defmulti-args true
}}}
ok, but then we can just add the reverse config in the default config for the tests?
one thing we’re doing with this approach however is duplicating default config into the test defaults.
ok… glad to do a PR on this, but it would make sense to set defaults for all existing options, right? the tests that failed now were just due to my specific configuration …
I'm trying the new :docstring-no-summary
linter. Why is the following positive?
(defn from-string
"Initialize UUID from string representation.
Accept only zero-padded representation."
[_])
dev\clj_kondo_docstring.clj:4:3: warning: First line of the docstring should be a capitalized sentence ending with punctuation.so if you enable :docstring-no-summary
you have also enabled :docstring-leading-trailing-whitespace
now ;)
@serioga same as here, but update the SHA: https://clojurians.slack.com/archives/CHY97NXE2/p1639585068083000
you can also wait for the build to finish and download the windows binary from appveyor
any test.check
users out there? please take a look at https://github.com/clj-kondo/config/issues/16 - if you have linting needs beyond what is already in the ticket feel free to leave a comment 🙂 edit: updated link
@maximilian Are you aware that you can write hooks for any library / custom macros?
yes, but how would they be shared? the standard way would be with the library, correct?
Yes, and if the lib isn't accepting the contribution then via https://github.com/clj-kondo/config
I want to figure out how you can include external configs as dependencies so you will still get them via the same mechanism
We have done something similar for https://github.com/clj-easy/graal-config
But there we hacked this by using :deps/root
so we can put everything in one repository
But perhaps we should just make libraries under the clj-kondo organization that we can deploy to clojars, so leiningen users will get them as well
so each library would contain just the config and you can include that library in your deps
yes, you would add this to your deps.edn / project.clj and then lint your project as you would always do. clojure-lsp does this automatically
@maximilian I guess we can just host these libs in one repository so we can use the same :deps/root trick as with graal configs and have an additional project.clj / build.clj in there for mvn deploys
yeah, I'd rather see a user-space thing first, eventually we can move it as a built-in but I'd rather not take on more libraries in clj-kondo as built-ins unless they are part of clojure/clojure