This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-08-20
Channels
- # announcements (3)
- # beginners (63)
- # calva (1)
- # cider (24)
- # clj-kondo (98)
- # cljdoc (8)
- # cljsrn (19)
- # clojure (106)
- # clojure-conj (2)
- # clojure-europe (5)
- # clojure-italy (5)
- # clojure-nl (8)
- # clojure-spec (8)
- # clojure-uk (13)
- # clojuredesign-podcast (7)
- # clojurescript (54)
- # core-async (1)
- # cursive (3)
- # data-science (1)
- # datomic (19)
- # fulcro (7)
- # hoplon (1)
- # off-topic (3)
- # re-frame (13)
- # reitit (1)
- # shadow-cljs (234)
- # test-check (10)
- # tools-deps (59)
- # unrepl (1)
- # yada (20)
FYI I haven't forgotten about testing https://github.com/borkdude/clj-kondo/issues/422 I'm seeing some filesystem permission errors writing the lockfile when using the cache with that binary, which I'm willing to blame on my recent upgrade to macOS Mojave until I can prove otherwise.
I've done all the things that were obvious to me, checked permissions on binary + dir, removed the dir (it can create the cache dir fine, just can't write the lockfile), checked for macOS extended attributes.
do you maybe have some anti-virus software running? I recently had an issue with this while compiling CLJS: it became terribly slow
in other news: clj-kondo now has a NixOS package: https://github.com/borkdude/clj-kondo/blob/master/doc/install.md#nixos
maybe java is whitelisted as a trusted process, but the binary clj-kondo is suspicious somehow?
Running without --cache
works well enough, I don't see the recur argument mismatch any more :thumbsup:
flycheck-clj-kondo seems to be working in my Emacs but it's not respecting ns inline config, I guess it should work?
i.e. trying something like this
{:clj-kondo/config
'{:linters {:redefined-var {:level :off}
:refer-all {:level :off}}}}
not all linters may work yet with the ns config. can you test with clj-kondo from master?
yes, I'll try, the one I'm using now was https://github.com/borkdude/clj-kondo/releases/download/v2019.07.31-alpha/clj-kondo-2019.07.31-alpha-linux-amd64.zip
and then after I release the next version, you can start using it from a normal package manager again
I got kondo nicely running in emacs which is good but the inline config to disable some warning sometime seemed like a good thing to get to work
I'm wondering can I somehow test that I didn't do a stupid mistake or contribute something if it doesn't work well yet
I don't have an open source repo here at the moment, testing on some internal code for now
I see you have a test like this
(is (empty? (lint! "(ns ^{:clj-kondo/config
'{:linters {:unused-namespace {:exclude [bar]}}}}
foo
(:require [bar :as b]))"))))
but this is different example here https://github.com/borkdude/clj-kondo/raw/master/screenshots/compojure-config.png
same result
FAIL in (extract-clojure-core-vars-test) (extract_var_info_test.clj:12)
expected: (contains? vars (quote future))
actual: (not (contains? #{} future))
FAIL in (extract-clojure-core-vars-test) (extract_var_info_test.clj:13)
expected: (contains? vars (quote transduce))
actual: (not (contains? #{} transduce))
FAIL in (extract-cljs-core-vars-test) (extract_var_info_test.clj:17)
expected: (contains? vars (quote clj->js))
actual: (not (contains? #{*target* ns js*} clj->js))
FAIL in (extract-cljs-core-vars-test) (extract_var_info_test.clj:18)
expected: (contains? vars (quote transduce))
actual: (not (contains? #{*target* ns js*} transduce))
I see now that I need to run script/test
first, without that there are some files missing
hmm it seems that you load the config "file" and use that for the filtering levels and don't use the ns local configs for filtering so it cannot possibly work
I have always had a need to disable some linting rules locally, and it makes sense to do that in code metadata, comments or so
I think the filtering of the results needs to be rewritten to work with the analyzer that actually resolves and propagates the local configs
for example I have some redefinitions of + - etc. in one file that reimplements some math concepts
or there is one function that does something more magic than the rest of the code ever needs to do
my experience is more from Java and JavaScript linters and they usually support turning off a warning here or there
(ns foo
(:refer-clojure :exclude [+ -])
(:require [clojure.core :as c]))
(defn + [a b]
(c/+ a b))
(prn (+ 1 2))
This is how you should do it in Clojure. Not using exclude while redefining things is bad.The linters that make sense to support as namespace local configs are supported, unless someone comes up with good examples of other linters that should be supported.
The reason why not everything is supported is that ns local config is a new feature and was only used for testing
clj-kondo has the philosophy that code should not be cluttered with tooling annotations, so where possible, use the global config
maybe you could just add a comment in the config section that local config does not work for every option
That is already documented. > Config takes precedence in the order of namespace, command line, .clj-kondo/config.edn. *Note that not all linters are currently supported in namespace local configuration.*
your specific example in tests uses ns local config but does not support level option
(is (empty? (lint! "(ns ^{:clj-kondo/config
'{:linters {:unused-namespace {:exclude [bar]}}}}
foo
(:require [bar :as b]))")))
vs. a hypothetical
(is (empty? (lint! "(ns ^{:clj-kondo/config
'{:debug true
:linters {:unused-namespace {:level :off}}}}
foo
(:require [bar :as b]))")))
since it's pretty clear level doesn't work then you could just mention that, I don't see a point trying to track code functionality completely in manually written documentation
I did notice it but thought that if the linter is supported then perhaps its options are
ah now I see what you mean. so you want a different level only for that namespace.. hmm
the problem in the current code is that the local configs don't get to the filter so it needs a slightly larger change than I can do myself at the moment but I'll do an issue tomorrow
I think the problem is that during output, the level from the global config. But you can override it I think, it's just ignored at the moment
so if we're luckily, it's just a minimal change. I'll look at it when I'll get to your issue
@gordonsyme_clojurians from the next version on, --cache
will become the default so you will have to do --cache false
, just as a heads up