@borkdude what would be necessary to provide a linter for the datalog query DSL arguments to datomic, datahike or datascript's q function?

@kordano this would probably pay off for our development work already

I think the following: 1) determine which fully qualified function calls need datalog linting 2) write a function that lints the datalog expression 3) combine 1 and 2 4) write unit tests 5) profit!

note that clj-kondo works with nodes instead of direct sexps values, but you can convert a node into it's corresponding sexp.

but it's preferable to work with nodes directly as you can be more specific in error locations and you can detect errors in the representation that would not even compile

^ @whilo

I'd be happy to stub out the start of this issue so you can fill in the rest of the details

ok, cool. i can easily provide a function that calls the datalog parser and returns either an error or whatever truthy value required

feel free to create an issue, some examples of expected inputs + errors and a link to that function

I might have to port that function to clj-kondo or use it directly, depends.

https://clojurians.slack.com/archives/CHY97NXE2/p1572175726225800 ^this was an interesting discussion, wanted to offer my 2¢ i think i can't even reach a consensus with myself on this one! sometimes i like the aliases all being uniform, and in some cases, i like to be able to name them differently imagine if you have a foo.api namespace that has been superceded by a foo.api2 namespace now imagine that you have a bar namespace that used to consume the foo.api namespace, so the ns declaration included [foo.api :as api]. and imagine that you want to migrate to the newer foo.api2, but the situation is kind of hairy and you need to still depend on something from foo.api too, for a while. so now bar needs to depend on both foo.api and foo.api2 we actually have a scenario like that at work, and we addressed it by requiring [foo.api2 :as api] and [foo.api :as oldapi]

so the issue there is that foo.api is aliased as api in some namespaces, and oldapi in others

and you would like to have them consistent?

because it's an error to use oldapi?

i think i like being able to use a different alias for foo.api in different namespaces, because i'm bringing it in within a different context

like in some namespaces, foo.api really is the "api," in others it's the "old api"

@dave well, there is the analysis export and you can write any kind of script with 2-for-Tuesday's in it that you want 🙂

i think that's a good solution 😄

i agree with dominic that there isn't consensus about this

@dave I would be very sad working on that. I'd never know if I could trust whether what I was looking at would do what I expected, because it might be old or new api. So I'd be constantly jumping to the ns form to remind myself any time I was looking at code using either.

yeah, I guess you could just call the old api old-api/ everywhere

I'd be fine with api2 for the new one until fully migrated. Although a linter would help me trust that people have done the right thing with being consistent.

hmm, that's a good point. i think i like the idea of the linter telling you about inconsistencies, and therefore encouraging you to come up with different aliases for different namespaces

i.e. don't call the old api "api" if there is also a new api that is being called "api" elsewhere

hmm, which raises an interesting question... if i have a namespace that requires pears :as p, and then another namespace that requires peaches :as p, is that a problem?

or is it just that you can't have pears :as p in one namespace, and pears :as pr in another namespace?

i'm thinking it's the latter

p should be consistent in what it refers to. So I'd go with "both".

i'm pretty sure i agree

as you're working in a project, you come to learn what p/ means in general

so you don't have to keep referring back to the ns form in whatever file you're editing

starting to make sense

what about libraries on the classpath? clj-kondo doesn't know what's a library and your own code

of course you can lint different directories with different configurations

i don't think you would want to apply these rules across "projects"

right, I mean when you do clj-kondo --lint $(lein classpath)

like if i'm using cheshire, and cheshire refers in clojure.string as s, then i don't want to not be able to call something else s in my project

but you do that only to populate the cache, so that's fine, you can ignore the warnings there

oh, hmm

so this could be a linter, I guess 🙂

https://github.com/borkdude/clj-kondo/issues/561

feel free to comment on it and to provide ideas, alternatives

maybe the value in the config map should also be a map so it can take options, like: except in this namespace

but maybe the point of this linter should be that it's consistent without exceptions 😉

i have a comment -- will add it to the issue

added a comment

added one more

https://github.com/borkdude/clj-kondo/blob/master/doc/dev.md

^ added some developer docs (design principles, but also practical things like how do you get a REPL)