manifold
manifold copied to clipboard
clj-kondo config
a lot of the macros in manifold (e.g. d/loop, d/let-flow, d/success-error-unrealized, etc.) confuse the static analysis that clj-kondo uses to lint for things like unknown bindings and other such things.
It would be nice to provide a clj-kondo config for those macros on the class path that lets clj-kondo know how to handle those macros. See https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md for docs
Thanks, this is on our to-do list. Of course, PRs welcome, too 😄
I believe the problematic public API macros have been resolved by #219. Is clj-kondo support for the internal macros (e.gsuccess-error-unrealized, deftype+) welcome as well?
Certainly! We're all big fans of clj-kondo, though it's not the friendliest towards macro-heavy code.
A few things to keep in mind:
- For private fns, you don't have to go the extra distance needed to export their kondo config to library users. It's fine as long as it works for people developing Manifold itself, aka us.
- For public fns, even undocumented ones, their kondo config should still be exported so library users get the benefit.
- For stuff like deftype+, double-check with potemkin. It's Zach's original funky macro lib, and kondo itself has some special handling for it (though only for the super-popular
import-vars, iirc). Manifold doesn't use potemkin proper, it just has some identical/similar macros (not sure which direction Zach copied deftype+ from/to). I added some basic kondo support to potemkin, but I don't recall if the deftype+ macro in manifold is close enough to steal its config. Also, my potemkin kondo config isn't super-sophisticated, it could easily be better.
I believe this issue is currently resolved by #224 and #219.