Clojurians Log v2

@imre Interesting, based on a conversation with borkdude my impression was that kondo generally had one config per (deps/lein) project, i.e. per module in IntelliJ language - is that not the case?

I can definitely add config for that.

@mgardner2 I'll add some debug logging to the next build to try to figure out what's going on there.

@imre I didn't do anything with the monorepo thing in this build because I'm not sure how to handle it properly, borkdude definitely says that each project should have its own config (https://clojurians.slack.com/archives/C02RPGUCQNB/p1753774298021349?thread_ts=1753753932.993599&cid=C02RPGUCQNB). I'm not sure what to do about polylith either, frankly polylith is so weird it's often really hard to know how to support it well without adversely affecting the experience for the 99% of people who don't use it.

Could perhaps the presence of a module-local clj kondo config trigger whether it should be initialized there?

So if you have a bunch of modules and only some with a config, none of the others should be initialized?

Yes, I thought about that, but there are lots of tricky edge cases. When initialising a new project which has no config at all but the user has said they always want to use kondo, the configs get created everywhere and there's not an easy way to identify which modules the user wants to initialise. If there are just a few modules with kondo configured, and the user opens a file from a module which is not contained within a module with kondo configured, but the user has said they want to use kondo everywhere, which config to use? And so on.

Cheers Colin, this solved the freeze for me.

I did notice something however with clj-kondo, I have a project (repository) where I keep the .clj-kondo directory with the config in the root, but the repo has multiple sub-projects. When I run clj-kondo in CI or in development, I use that repo-global config and don't keep any subproject-local ones. When I loaded the project, Cursive asked if I want clj-kondo, to which I said yes, then it proceeded to initialize clj-kondo and create new .clj-kondo subfolders in all subprojects (which Cursive auto-detects as modules). I'm not convinced I want to change my linting workflow to per-subproject tbh.

still not seeing any kondo findings in IntelliJ. I believe the relevant settings are enabled

@cfleming that's generally true, but I'd say monorepos will have all sorts of weird stuff. For this monorepo we only have a single clj-kondo config, at /.clj-kondo/config.edn and nowhere else. Should Cursive perhaps use the presence of a module-local clj-kondo config as a guide? As in, if there is no config in a module, don't init there? Polylith projects should also fall under this to some extent. I understand Cursive creates modules out of every subproject in a polylith repo. But subprojects under the components and bases folders in a Polylith workspace might not have all their dependencies declared in their deps.edn's, so linting those on their own would create false positives around unknown namespaces and such.