Support multiple config.edn files

[juszczakn]

It's possible I'm just missing this and it's already possible, but it seems like cljfmt currently doesn't support a way to split up the config across multiple files?

clj-kondo supports projects exporting their own configs, such that downstream projects can import and make use of them. This sort of feature seems like it would be super helpful in cljfmt as well!

For example, a utility library that defines a common macro used by lots of projects could specify a cljfmt.edn, and downstream projects could choose to import and merge that config into their own root config in some way.

It wouldn't even necessarily have to be as complicated as what clj-kondo has, simply being able to specify other config files in your root config file, and having all the configs deep-merged into one seems like it would be a useful first step to me.

Something like being to specify this in your config.edn:

{:additional-configs ["../other-project/.cljfmt.edn"]}

[weavejester]

I don't believe there's any support for this currently. Allowing cljfmt to find config files on the classpath would be useful functionality. An :extra-configs or :include-configs key might also be useful.

[juszczakn]

@weavejester just made #337 as a quick poc, I have no idea if it's even correct, but something like that as the basic idea?

[juszczakn]

@weavejester I updated the poc, I think it's at a state where it might be worthy of an initial code review, although it's still a little rough maybe

[TuggyNE]

I'm interested in having this for a library I'm working on, which has some syntactically-relevant macros. Any progress on getting this or similar reviewed and merged?

[weavejester]

I'm interested in having this for a library I'm working on, which has some syntactically-relevant macros. Any progress on getting this or similar reviewed and merged?

I'm waiting on the PR author to implement the changes in the last review.

[TuggyNE]

That PR looks pretty close to done. Maybe I can try to get something similar across the line. In particular, making :extra-configs recursive seems like a fairly small change.

[juszczakn]

It sounded like from this comment on the PR:

I'm beginning to think that this issue might be better solved via a different means entirely. For example, if the use-case is just supporting extra indentations in libraries, we could create a indent resource in a standard location.

that the current approach wasn't really ideal and should be scrapped. Which I kinda agree with, I prefer clj-kondo's approach to this problem, but I never came back to this as the issue kinda fell off my radar.

Is the clj-kondo approach what we want to do? If so, then this extra-configs PR should probably get entirely reworked.