There's a lot of stuff here. I think it's better to put this in a Github reo that I can run locally

But surely

WARNING: file jdsl/basic not found while loading hook
WARNING: error while trying to read hook for jdsl.basic/do: Could not find namespace: jdsl.basic.

Thanks for reply Sir. Repo is ready. https://github.com/Vikasg7/jdsl checkout to clj-kondo-hook branch.

The issue is with:

(:require [jdsl.basic :as jb :refer [run]])

if you want to run this namespace in the clj-kondo hooks interpreter, you need to add it to the config

oh... what is the keyvalue pair to add it?

why do you want to do this?

What is the purpose of returning:

(list run form 'ts)

you can read the do macro doc string.

every form is a parser and I want to run the parser with the token-stream ie. ts as argument and pass the ts to the next parser call.

I think what you are looking for is really:

(ns hooks.basic
  (:refer-clojure :exclude [do])
  (:require [jdsl.basic :as-alias jb]))

(defn- expand->bindings 
  "Expands `parser`, `(parser)`, `(a <- parser)`, `(parser args)` forms 
   in the do macro to `let` bindings."
  [form]
  (if-not (list? form)
    [['_ 'ts] (list `jb/run form 'ts)]
  (if (= 1 (count form))
    [['_ 'ts] (list `jb/run (first form) 'ts)]
  (let [[sym op prsr] form]
  (if (= '<- op)
    [[sym 'ts] (list `jb/run prsr 'ts)]
    [['_ 'ts] (list `jb/run form 'ts)])))))

(defn- expand->body
  "Expands the `parser`, `(parser)`, `(parser args)` form 
   in the do macro to `let` body"
  [form]
  (if-not (list? form)
    (list `jb/run form 'ts)
  (if (= 1 (count form))
    (list `jb/run (first form) 'ts)
    (list `jb/run form 'ts))))

you don't want to return a list with the function from your library, but a list with a symbol that points to the function of your library

yes, it sounds correct, I think I might have tried api/token-node 'jdsl.basic/run along that spirit.

lemme test above.

it worked thanks, so will it work If I lein-git-down and use this as dependency in my other repo? Actually, I use this library to make parser for the interpreter, I am writing in clojure. Also, is :as-alias any different from :as here? Thanks for the quick help. Really Appreciate it.

as-alias only introduced an alias, but does not load a library

you can read here how to "export" your configuration so it will be visible to anyone who uses your library: https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#exporting-and-importing-configuration

here are lots of examples: https://github.com/clj-kondo/clj-kondo/discussions/1528

Sure, thanks once again. You are a life savor. I was stuck on this for 2 days.

I don't know, but you can include a newer clj-kondo as an extra dependency so lein-clj-kondo uses that one

also you can probably just use a git blame on src/clj_kondo/impl/config.clj to check yourself

also, there is the clojure-lsp diagnostics which should behave the same as the editor + extra linters you see in the editor

Thanks, @U04V15CAJ and @UKFSJSM38, I will try doing these things soon

I attempted using [clj-kondo "2023.05.26"] as a managed dependency, but lein-clj-kondo does not pick this up when I use it as a plugin. Am I supposed to use exclusions?

OK I think I see the problem — lein-clj-kondo is not evaluating code in the project, so it is always going to use its own clj-kondo version, regardless of what the project specifies

Does lein not allow to insert newer deps into plugins? That would surprise me about a dep management tool

The problem is there are multiple evaluation contexts in leiningen

To ensure proper isolation, you can either eval in project, eval in leiningen, or even set up your own classpath entirely

It looks like lein-clj-kondo evaluates in a context isolated from the project, so there is nothing the project can do to mess with the plugin

Likewise, whatever dependencies the lein-clj-kondo plugin uses will not mess with the project’s classpath

so while you are able to use exclusions, managed dependencies, etc. in a project, none of these will ever end up affecting lein-clj-kondo since lein-clj-kondo does not eval-in-project to begin with

for now i have decided to fork lein-clj-kondo, update the dependency, and deploy it in a private maven repository

Feel free to PR the update

after some investigation, i realized that https://github.com/clj-kondo/clj-kondo/issues/2001 made the following NOT trigger misplaced docstring

(deftest foo
  "not a docstring"
  (is ...))

so clojure-lsp is using an older version of clj-kondo before this was merged, presumably, because clojure-lsp does warn me about it

this resulted in a bit of a rabbit hole finding out why clojure lsp would complain about code that passed lint tests in CI 😄

% clojure-lsp --version
clojure-lsp 2023.02.27-13.12.12
clj-kondo 2023.02.17

I am working on a project with a friend who is very new to clojure and makes a lot of silly mistakes. So I have many clj-kondo linters set to :level :error so that he avoids many bad writing styles. In particular, he attempted writing a docstring for a test, but I dont think deftest even accepts docstrings. The :misplaced-docstring linter was helpful in finding this mistake. But later versions of clj-kondo no longer do this for deftest forms.

AFAIK deftest never took a docstring

Yeah. It looks like someone requested to make the :misplaced-docstring linter not warn about strings in a deftest form, though I personally liked the old behavior.

In general this should be reported as unused-value but it doesn't do this right now. I'll fix that

e.g.:

https://github.com/clj-kondo/clj-kondo/issues/2132

BTW you have a outdated clojure-lsp, so outdated kondo, latest version is from July, you are using one from February