@U061V0GG2 The solution, if you want to have a shared clj-kondo config is to add {:config-paths ["../../clj-kondo-shared"]} or so in your project .clj-kondo/config.edn

the path is relative to the .clj-kondo directory

Yeah I can workaround this by adding config.edn in each of the 10 modules, but seems a bit incovenient to add these for clojure-lsp, while clj-kondo command works fine.

in this case I'll defer to @UKFSJSM38 :)

For deps mono-repo, I suggest opening a single clojure-lsp session at the mono-repo project root, this would avoid multiple clojure-lsp process taking your machine resources, would make you navigate between submodules easily and you could have a single .clj-kondo/config.edn in the the monorepo root as well

clojure-lsp is a mono-repo deps itself, you can use it as example, but the idea is to have a deps.edn at the root with dev alias linking all the submodules, similar to how polylith does

https://github.com/clojure-lsp/clojure-lsp/blob/master/deps.edn#L2-L5

Hmm, makes sense. Also removes need for n+1 processes. We even already have something like that to generate classpath for some clj-kondo operations.

seems like you should take a look at clojure-lsp diagnostics which takes care of all of that :) https://clojure-lsp.io/api/cli/

Yeahh... well others aren't using LSP and are "conservative" about the tooling.

Hum, I thought we fixed that kind of issue to fallback to clj when an unknown extension

Well even when it’s failing it does seem to correctly detect clojure:

[Trace - 09:49:25 AM] Sending notification 'textDocument/didOpen'.
Params: {
  "textDocument": {
    "uri": "file:///Users/mtwomey/Git_Repos/babashka-scripts/update-gcp-job-env",
    "languageId": "clojure",
    "version": 0,

yeah, that's correct, what is giving this error is clj-kondo when we tell it to lint the file. I noticed we are indeed checking if the extension is unknown to not pass any lang to clj-kondo https://github.com/clojure-lsp/clojure-lsp/blob/5488311a2f135741abb7d6a8fb5f07472a7f17c5/lib/src/clojure_lsp/kondo.clj#L305-L306

so clj-kondo would use the clj as default

what clojure-lsp version you are using?

looking

Is there a quick command to get version?

lsp-clojure-server-info , should print a map and there will have server-version

Ah ok:

:server-version "2022.10.05-16.48.26-nightly",
 :clj-kondo-version "2022.10.05",

I think we fixed after this version :)

latest release should fix

Awesome, thanks so much. I will pull this down. Appreciate your help!

Reporting back: Updating LSP version did indeed fix the issue!! Thanks again.

Nice! You're welcome!

One small followup @UKFSJSM38: Various lsp functionality is still a bit “weird” for me in files without extensions. lsp-docs and so forth. A specific example is when I do an lsp-find definition it’s not found. In the log I see:

[Trace - 11:50:05 AM] Sending request 'textDocument/definition - (18)'.
Params: {
  "textDocument": {
    "uri": "file:///Users/mtwomey/Git_Repos/babashka-scripts/update-gcp-job-env"
  },
  "position": {
    "line": 22,
    "character": 22
  }
}


[Trace - 11:50:05 AM] Received response 'textDocument/definition - (18)' in 20ms.
Result: null

(this same functionality works if I add the .bb extension)

that happens probably because of missing classpath, lsp is running in "basic mode", to be able to have valid classpaths you wouldneed a bb.edn file with :srcs correct and the script in there

https://github.com/clojure-lsp/clojure-lsp/blob/master/bb.edn#L1

learn more about it https://clojure-lsp.io/settings/#classpath-scan

Ok - but how come it works if I simply add a .bb extension to the file name?

(also note - many things do work it detects references correctly, lsp-rename works, …etc)

hum, maybe there is something to improve in lsp, TBH is not well supported files without extensions

Probably not worth it, a lot of lsp code expect files to have extensions, maybe it's easier to rename to .bb?

Fair enough. I don’t object to digging in myself a bit and maybe do a PR. Could you give me a general pointer as to where I might start looking?

Sure, I actually have a clue where is the issue: we use in a lot of places xf-same-lang https://github.com/clojure-lsp/clojure-lsp/blob/master/lib/src/clojure_lsp/queries.clj#L264, so it's checking if the definition lang (.clj) matches the current file (:unknown), that's probably the issue, we could maybe improve xf-same-lang to treat unknown as clj at least

Ok - thanks sir. I realize having the extension isn’t a big deal for most people. Just a small preference for me - so trying to improve it a little will just be a learning opportunity for me. Will keep you posted.

Ok - when you have a second @UKFSJSM38, I’d like your thought. I dug around and learned quite a bit about this code base. The issue turns out that the file uri looks like this: :uri "file:///Users/mtwomey/Git_Repos/babashka-scripts/update-gcp-job-env" (logging var-usage variable) The check in defn elem-langs [element] - that uses shared/uri->available-langs. shared/uri->available-langs has no case for no extension. As a test, I did this:

modified   lib/src/clojure_lsp/shared.clj
@@ -135,7 +135,7 @@
     (string/ends-with? uri ".bb") #{:clj}
     (string/ends-with? uri ".cljd") #{:clj}
     (string/ends-with? uri ".clj_kondo") #{:clj}
-    :else #{}))
+    :else #{:clj}))
 
 (defn ^:private conform-uri
   "Changes and returns URI given FORMAT-SETTINGS:

Yeah, I think it's ok to do that as it's the same kondo does for unknown langs, would be nice to have a find definition test for that as well

Ok - cool. Will add a test also and create a PR.