This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-11-13
Channels
- # aleph (1)
- # announcements (18)
- # babashka (11)
- # beginners (112)
- # business (1)
- # calva (19)
- # cider (8)
- # clj-kondo (63)
- # cljsrn (10)
- # clojure (188)
- # clojure-australia (1)
- # clojure-dev (38)
- # clojure-europe (112)
- # clojure-nl (3)
- # clojure-provo (1)
- # clojure-spec (22)
- # clojure-uk (108)
- # clojurescript (37)
- # cryogen (4)
- # cursive (8)
- # data-science (1)
- # datomic (13)
- # emacs (9)
- # events (1)
- # fulcro (26)
- # funcool (3)
- # graalvm (2)
- # graphql (11)
- # helix (8)
- # jobs (1)
- # jobs-discuss (7)
- # nrepl (3)
- # off-topic (72)
- # pathom (10)
- # pedestal (1)
- # reagent (6)
- # reitit (7)
- # remote-jobs (1)
- # shadow-cljs (28)
- # xtdb (12)
I'm using (create-ns) and (alias) manually to create some namespaces only for the purpose of spec. Wonder if there is a way I could do it so clj-kondo wouldn't show warning Unresolved namespace marketplace. Are you missing a require? (clj-kondo-clj)
Though I could switch the function to a macro that returned an (alias 'foo 'bar)
if that can help
They're not dynamic. Like the namespace is in the code. I wrap a call to create-ns and alias in a function. And I call that function with a hard-coded symbol
Maybe I could hook into clj-kondo and add symbols passed too my custom function to it's set of known alias? Is that possible?
https://github.com/borkdude/clj-kondo/blob/9aaee5023a5da511cedd3b77bd64a35a51636416/src/clj_kondo/impl/analyzer.clj#L701 alias is supported already
Hum, this makes me wonder, does inlining work with clj-kondo? Like with definline or :inline meta ?
(ns foo)
(create-ns 'com.bar.baz)
(alias 'bar 'com.bar.baz)
::bar/foo
This lints fine. So I'd try hooks.yes, a hook could work. but clj-kondo could also be tweaked to recognize the (alias 'foo (create-ns 'bar))
pattern is that is used a lot
But I have this wrapped in a utility function which is in another namespace, which I call like so:
(defalias 'alias 'namespace)
and you can also do that yourself via a hook right now. or use #_{:clj-kondo/ignore [:unresolved-namespace]}
. This is only needed in the first occurrence.
hi, I get error indications from clj-kondo when I use async/alt!
in clojurescript, the errors report the binding symbol in a result-expression as unresolved symbol
, anybody else seen this? works fine in clojure..
hmm, I’m not really familiar with slack and how to send snippets, that was not what I intended
(ns repro
(:require-macros [cljs.core.async.macros :refer [go alt!]])
(:require [clojure.core.async :as async]))
(let [ch (async/chan)]
(go
(alt!
ch ([value]
(println value)))))
when I have that code in a cljs file in VS Code, I get error squiggly on the value
binding symbol
Yeah, I see. If you write:
(let [ch (async/chan)]
(go
(async/alt!
ch ([value]
(println value)))))
then it goes away, but I'm not sure if that's valid in CLJSclj-kondo understands clojure.core.async/alt
but it doesn't have a special rule for understanding the CLJS way of using that
You can fix it now with this config:
(ns repro
{:clj-kondo/config '{:lint-as {cljs.core.async.macros/alt! clojure.core.async/alt!}}}
(:require-macros [cljs.core.async.macros :refer [go alt!]])
(:require [clojure.core.async :as async]))
(let [ch (async/chan)]
(go
(alt!
ch ([value]
(println value)))))
I had assumed :lint-as was only for macros for some reason, but ya, happy to see it works for functions as well
yeah, clj-kondo doesn't care about macro or function, it only cares about the surface form
Another question, for Alias consistency
it seems you need to configure it. Would there not be a way that it just complained on alias that differed in a code base? Like if I had two namespace, one where foo.bar is foo and another where foo.bar is bar, then both alias would show a warning saying they are inconsistent with one another?
@didibus That has come up in the issue when writing that linter. The reason we didn't do that is that currently clj-kondo doesn't read information about other namespaces other than vars from the cache. And you would have to make a choice either way: like what if two namespaces have str and two other namespaces have s. You would have to specify one of both in the config then anyway. So it just made the most sense to just start out with a baseline
You can retrieve the aliases from all namespaces from the analysis config yourself and then spit out some baseline, probably
That makes sense, though, I think an automatic one would be much more useful. Generally, I don't care if its s
or str
, but I care that whichever it is is the same everywhere. So I'd expect that the first one someone uses would become the standard, as the next person to alias it would see the warning: Inconsistent alias, aliased as s in foo
And so they'd fix their inconsistent usage. But I recon the added complexity of doing so due to needing info from other namespaces for it.
The problem is that this requires knowledge of an entire code-base, while linting only one file (in editor usage)
You can write such a linter yourself based on the analysis output of course, but then you would not see it in your editor
We could write to a special cache file that this linter could read from which would be an index of namespace (clojure.string) -> frequency table of aliases, or something? I haven't thought this through in detail, but feel free to think more about it.
Seed is planted 😛 Its not my most important concern, just thought about it as I was reading on the linter
Re: namespace aliases -- is there a linter for sanity-checking the alias (in the absence of configuration) based on the common guideline that a namespace should be aliased to the last segment of its name (if that wouldn't be ambiguous in a file)?
Is that a common enough guideline to be worth implementing?
Obviously there are exceptions (`clojure.spec.alpha :as s` and clojure.string :as str
are the most common I've seen in books and tutorials and it seems that datomic.client.api :as d
is canonical).
Maybe some built-in (overridable) defaults for common nses?
yeah, there could be some predicate (that can be executed with sci) to determine the desired alias
> is there a linter for sanity-checking the alias No > Is that a common enough guideline to be worth implementing? Possibly
or sci.core :as sci
, so I think it would maybe be hard to come up with a predicate that would satisfy the entire community
Also, the function would have to give a unique answer for a given lib. What if there is already an e
in the config, what would it recommend: ed
, e2
?
I'll give it some thought, and see if I can come up with a good heuristic. In the presence of ambiguity -- either against the config or other aliases in the current ns -- just not running the check would seem to be the safest option.