Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-10-25

Channels

#clj-kondo
<
2022-10-25
>
Aleks14:10:03

clj-kondo complains about an unresolved symbol in s/def . Same works perfect with s/fdef . What a recommended way to resolve it?

borkdude14:10:30

@zelark You should probably use a keyword there

borkdude14:10:21

(s/def ::whatever (s/any? *))

Aleks14:10:09

yeah, a keyword works, but with a symbol it’s also a valid expression. We use it to refer to the same spec for a fn in few places.

borkdude14:10:25

Hmm ok, this needs to be fixed in clj-kondo then. Issue welcome

Aleks14:10:37

Thanks, my colleague will do

vemv19:10:45

I have a dep management issue when running lein-clj-kondo on a particularly contrived project. These are the relevant bits: 

Syntax error compiling at (clojure/tools/reader/edn.clj:1:1).
	at clojure.lang.Compiler.load(Compiler.java:7652)
	at clojure.lang.RT.loadResourceScript(RT.java:381)
	at clojure.lang.RT.loadResourceScript(RT.java:372)
	at clojure.lang.RT.load(RT.java:459)
	at clojure.lang.RT.load(RT.java:424)
	at clojure.core$load$fn__6856.invoke(core.clj:6115)
	at clojure.core$load.invokeStatic(core.clj:6114)
	at clojure.core$load.doInvoke(core.clj:6098)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.core$load_one.invokeStatic(core.clj:5897)
	at clojure.core$load_one.invoke(core.clj:5892)
	at clojure.core$load_lib$fn__6796.invoke(core.clj:5937)
	at clojure.core$load_lib.invokeStatic(core.clj:5936)
	at clojure.core$load_lib.doInvoke(core.clj:5917)
	at clojure.lang.RestFn.applyTo(RestFn.java:142)
	at clojure.core$apply.invokeStatic(core.clj:669)
	at clojure.core$load_libs.invokeStatic(core.clj:5974)
	at clojure.core$load_libs.doInvoke(core.clj:5958)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.core$apply.invokeStatic(core.clj:669)
	at clojure.core$require.invokeStatic(core.clj:5996)
	at clojure.core$require.doInvoke(core.clj:5996)
	at clojure.lang.RestFn.invoke(RestFn.java:619)
	at edamame.impl.parser$eval12811$loading__6737__auto____12812.invoke(parser.cljc:1)
	at edamame.impl.parser$eval12811.invokeStatic(parser.cljc:1)
	at edamame.impl.parser$eval12811.invoke(parser.cljc:1)

...

Caused by: java.lang.IllegalAccessError: reader-error does not exist
	at clojure.core$refer.invokeStatic(core.clj:4237)
I tried bumping tools.reader to no avail. Does it ring a bell? (doesn't look too hard - will keep trying in the meantime!)

Alex Miller (Clojure team)19:10:20

this might be a tools.reader version conflict with the version aot'ed into clojurescript

borkdude19:10:56

the vendored version in CLJS uses a namespace prefix, I think?

Alex Miller (Clojure team)19:10:13

but it didn't in older versions

vemv19:10:00

although the clojurescript bump thing was a good lead (and something I'll try to keep in my head) finally it was a matter of adding this exclusion: [lein-asset-minifier "0.4.6" :exclusions [org.clojure/tools.reader]] legacy projects / plugins. 🌀

👍 1
Noah Bogart20:10:26

any interest in a linter that checks for (-> some-obj (. interopCall) (. interopCall2) (. interopCall3))? It would look for thread-first macros that all have interop calls and suggest using (.. some-obj (interopCall) (interopCall2) (interopCall3)) instead

borkdude20:10:17

Not interested - after macroexpansion this is all the same?

borkdude20:10:01

I'm more interested in the dynamic var linter 😉

Noah Bogart20:10:31

heh I started work on that last night but don't have much free time at the moment.

vemv20:10:10

silly observation but -> is so perfect :star-struck: there's also (-> some-obj .interopCall .interopCall2 .interopCall3) I'd like the versatility of -> - for misc ops, interop, data access, math sometimes. All with the same keystrokes (I have a life-changing snippet that expands - to (-> $1)

Noah Bogart20:10:21

I prefer to be consistent in these kidns of things, and like nesting a do block inside of a when, seems like "use the semantically correct tool"

borkdude20:10:22

yes, I like ->

borkdude20:10:06

do is different, a redundant do clears up nesting and thus noise, but -> vs .. doesn't reduce any noise imo

Noah Bogart20:10:44

Sure. If you don't want it, then I won't open an issue for it.

Noah Bogart20:10:48

Have you thought about qualifying/namespacing the linter keywords? :style/consistent-alias, :lint/loop-without-recur, :syntax/duplicate-map-key, :performance/redundant-fn-wrapper etc

Noah Bogart20:10:02

On the one hand, it would require some sort of "conversion" step to maintain backwards compatibility, but on the other hand, it would make space for things like "disable all style linters" and increase the meaning of each linter name

borkdude20:10:55

I've considered it but not adopted it

Noah Bogart20:10:16

Well, I'm willing to help if you decide to go for it

borkdude20:10:07

I'd rather see work happening elsewhere

Noah Bogart20:10:37

sadly, I am driven entirely by whim 😉

☕ 1
dpsutton22:10:46

Is there an alias for duplicate test names? Every now and then I end up with (deftest foo …) and then another (deftest foo …) in the same file and of course only one will run. Doesn’t take too long to figure out so no huge need for it. Just would be a nice quality of life perhaps

borkdude22:10:24

This should result in a redefined var warning

dpsutton22:10:57

Oh lovely. I’ll double check