If your team is going to rely on a shared LSP config, I'd argue they should also standardize their dev envs to the point that no one needs to make "local config overrides"...

The teams I work in have a shared configuration only for CI and not editors. For example, I set up a clj-kondo configuration that the team agrees upon to be used by the CI workflow and then the team is free to have their own specifics for the editor experience (if they choose). I am curious why a shared LSP config is required. I assume the most valuable aspect is standardising the formatting of code via the cljfmt, which itself can be defined in a separate file from the .lsp/config.edn file, leaving the rest of the LSP setup to be tailored to each team members preference (and desired level of feedback). If that assumption is correct, then perhaps that is a useful approach.

Our project-level .lsp/config.edn has

{:source-aliases #{:build :dev :test}
 :paths-ignore-regex [".*/googlepay/java.clj"]
 :clean
 {:ns-inner-blocks-indentation :same-line
  :ns-import-classes-indentation :same-line
  :sort {:refer {:max-line-length 1}}}}

Thanks for help. 👍

@U34K4458X clj-kondo does support this btw, for the stubborn developer that still wants to see more warnings than their team mates :) You can use CLJ_KONDO_EXTRA_CONFIG_DIR for extra configuration locally, this is exactly for this use case.

oh thats cool, good to know. Thanks @U04V15CAJ. In my workflow I've babashka script + gum to start a repl, it asks few questions on what aliases and extra paths I want to add then starts the repl and modifies .lsp/config.edn

niice :)