Metadata configuration sometimes fails to apply on the first Kondo run about clj-kondo HOT 10 CLOSED

I'm sorry if I came off as entitled. Please understand that Kondo is mandated by my work, I did not choose any of this, and I lost an entire day to debugging this problem. After spending a lot of time understanding the behavior and writing a detailed report of my problems, I got a dismissive "This is how it's supposed to work" reply after five minutes.

What you're sensing isn't entitlement, but an attempt to moderate an extreme amount of unhappiness and provide some constructive feedback which could prevent others from repeating the deeply negative experience I suffered.

I think you're taking frustrations from your place of work out on a very productive and generous open source developer. Not a good look in my eyes.

from clj-kondo.

I'm not sure what you mean by "similar."

What mean with similar is configuration that spans multiple namespaces. You configure the behavior of a function/macro locally in file A but the function/macro is used in file B where you should see the effect.

Since the languages you mention don't support macros, they might not have this problem.

Maybe it's best if you forget about inline configuration for now and just focus on :config-in-call..

Also I would like you to refer to https://clojure.org/community/etiquette. I sensed a hint of entitlement. This is a free tool that I have poured countless hours of work into. The tone you started this issue with doesn't encourage me to help you any further. Maybe I interpreted it wrong.

from clj-kondo.

I think I've explained it sufficiently and I'm updating the documentation right now, although it already (briefly) explained how it works. Feel free to create new issues, but please don't take out your frustration on me and keep it to the point.

from clj-kondo.

This is how it's supposed to work. When linting code that has metadata configuration, clj-kondo writes this to a local file. Next time you run clj-kondo this configuration goes into effect. This is not a bug.
I recommend running: clj-kondo --lint "$(clojure -Spath)" --dependencies --copy-configs before actually linting your code. This will set up clj-kondo will all the necessary information about your dependencies and will also gather all the metadata configuration for subsequent use.

This is also suggested here:

https://github.com/clj-kondo/clj-kondo?tab=readme-ov-file#project-setup

from clj-kondo.

This is how it's supposed to work. When linting code that has metadata configuration, clj-kondo writes this to a local file. Next time you run clj-kondo this configuration goes into effect. This is not a bug.

It's a documentation bug even if it's not a behavior bug. The section on using metadata configs doesn't mention the requirement that you run Kondo and commit some, but not all, of the files it creates when you do that.

Whether you want to call it a bug or not, it's a horrible experience.

I recommend running: clj-kondo --lint "$(clojure -Spath)" --dependencies --copy-configs before actually linting your code. This will set up clj-kondo will all the necessary information about your dependencies and will also gather all the metadata configuration for subsequent use.

Note that this behavior is only triggered if I have already done this, but at a time before the macro has been added. As this is in the "project setup" section of the documentation, my expectation is that it's intended to be run once, when the project was set up. I encountered the problem on a years-old codebase, which I had just added a new macro to.

Is it expected that this command needs to be run every time a macro is added? If so, is that documented?

from clj-kondo.

Whether you want to call it a bug or not, it's a horrible experience.

If you don't like the experience, you can configure your macro directly in .clj-kondo/config.edn.
See https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#unrecognized-macros for all the options.

Is it expected that this command needs to be run every time a macro is added? If so, is that documented?

If you have a .clj-kondo directory, the necessary configuration will be stored there, after visiting the file with the macro in your editor. If you haven't visited the file with the macro in your editor, then you need to do either that, or execute the above commands. It all boils down to: clj-kondo needs to process the file with the metadata config, before that config is applied to the rest of your project.

I'll take a look at documentation improvements, thanks for the feedback.

from clj-kondo.

It all boils down to: clj-kondo needs to process the file with the metadata config, before that config is applied to the rest of your project.

I note that I have used many other linters for many different languages and formats, and Kondo is the only one which has had this requirement. It's very surprising behavior.

I'll take a look at documentation improvements, thanks for the feedback.

Some other things that would have made today less unpleasant for me:

• If whatever updates the metadata was a separate command, rather than a side-effect of a different command.
• If the linter gave me better direction (like "update your metadata cache") instead of behaving exactly the same as before I added the metadata.

from clj-kondo.

The issue is that clj-kondo needs to be informed about a macro defined in namespace A while it's linting namespace B, C, D ... and other namespaces that are using namespace A. Clj-kondo does so by saving information from namespace A to the .clj-kondo directory, such that when it lints namespace B it doesn't first have to lint namespace A. Can you show me an example of a similar setting for other languages and linters? I'd be curious to learn.

from clj-kondo.

Can you show me an example of a similar setting for other languages and linters? I'd be curious to learn.

I'm not sure what you mean by "similar." If you mean, a linter which allows for configuring its errors inline, that's most other linters. If you want examples, there's Hadolint, Yamllint, and Flake8, all of which I use daily, all of which let you add an inline ignore which takes effect immediately & doesn't require doing anything else.

Given my prior experience and no mention of Kondo's requirements for special handling of inline configs in the docs for that feature, I didn't expect anything else was required.

If the question is "what other linter caches information in the way Kondo does," I don't have an answer. No other linter has required me to care about its internal implementation details in order to use.

from clj-kondo.

I'm sorry if I came off as entitled. Please understand that Kondo is mandated by my work, I did not choose any of this, and I lost an entire day to debugging this problem. After spending a lot of time understanding the behavior and writing a detailed report of my problems, I got a dismissive "This is how it's supposed to work" reply after five minutes.

What you're sensing isn't entitlement, but an attempt to moderate an extreme amount of unhappiness and provide some constructive feedback which could prevent others from repeating the deeply negative experience I suffered.

from clj-kondo.