clj-kondo

seancorfield 2024-11-23T23:14:37.947509Z

I've noticed in some of my projects, .clj-kondo contains an imports folder with the various dependencies' configs and hooks inside, whereas other projects have those dependencies' folders at the top-level. What determines that?

borkdude 2024-11-23T23:16:41.495469Z

the imports directory is a new feature. if there were already previously imported libraries top level inside of the .clj-kondo dir, it won't create it since you would get duplicates

seancorfield 2024-11-23T23:17:17.349389Z

Ah, so if delete the old stuff and then re-run lsp, it'll create imports instead?

borkdude 2024-11-23T23:18:15.369019Z

yes. more info here: https://clojurians.slack.com/archives/CHY97NXE2/p1716222464894789

👍 1
seancorfield 2024-11-23T23:18:28.102699Z

And would you recommend committing imports or ignoring it for git? I'm thinking of cleaning up my projects a bit...

borkdude 2024-11-23T23:19:19.239369Z

I think it makes sense to commit them so people don't have to imports those first to get a working linting configuration

👍🏻 1
imre 2024-11-24T10:27:04.340889Z

I tend to not commit those to avoid churn when deps change

borkdude 2024-11-24T10:27:56.162829Z

in my experience there isn't that much churn in clj-kondo configs from dependencies over the lifetime of a project, but YMMV

imre 2024-11-24T10:30:34.152679Z

As we add hooks and configs to internal libs and update those in services I believe those get reflected in inported configs

borkdude 2024-11-24T10:31:43.734569Z

I see

imre 2024-11-24T10:36:07.280489Z

It isn't much but since reimporting is dead simple, I just chose to not have the same thing checked into multiple repos as generated code

borkdude 2024-11-24T10:37:45.688339Z

yeah that makes sense.

imre 2024-11-24T10:42:02.987709Z

For our case this works well at least. Its good to have the option to decide whether to check them in or not

👍 1
imre 2024-11-24T10:42:41.629909Z

Adopts well to individual needs

seancorfield 2024-11-24T15:44:26.416679Z

At work we only have one repo so committing clj-kondo configs is part of "upgrading dependencies" which is an action associated with a ticket, that affects just "one" thing. I can see how this would become annoying when you have a lot of different repos to deal with -- I only noticed it because I was comparing the structure of several of my OSS repos 🙂

👍🏼 1