Merge multiple file configs

[knightpp]

Is your feature request related to a problem? Please describe.

I use treefmt.withConfig from nixpkgs and it generates a wrapper like treefmt --config-file /nix/store/vykk3qvdjrnmvgp4pmw4jy2kdb8321fm-treefmt.toml.

Describe the solution you'd like

I'd like to have the wrapper but also configure exclusions per project. I think treefmt.toml in root dir should be merged with other configs into the global config.

Describe alternatives you've considered

I've tried setting exclusions in treefmt.toml but it didn't work.

excludes = ["assets/temml.min.js"]

Though, TREEFMT_EXCLUDES env var worked.

Additional context

[jfly]

But it seems passing the CLI argument results in ignoring other configuration sources?

IIUC, this sounds like a bug. Can you file a separate issue for this with more detail?

I think treefmt.toml in root dir should be merged with other configs into the global config.

This is a feature request. One that I personally believe is out of scope for treefmt. But let's see if others chime in.

[knightpp]

But it seems passing the CLI argument results in ignoring other configuration sources?

IIUC, this sounds like a bug. Can you file a separate issue for this with more detail?

Never mind, I didn't mean it like that.

If merging configs is out of scope, I'd be happy with just exclusion file that is also read and merged on treefmt invocation. Maybe there's some other way to add project specific exclusion that I am not aware of?

[jfly]

I'd like to have the wrapper but also configure exclusions per project.

It sounds to me that you have a globally installed treefmt? That is not something I would expect anyone to do. You should be setting up a per-project treefmt in a devshell and/or as a nix fmt entrypoint.

[knightpp]

I'd like to have the wrapper but also configure exclusions per project.

You should be setting up a per-project treefmt in a devshell and/or as a nix fmt entrypoint.

Makes sense. But, I have a lot of small repos, so it's not feasible to update everything. The current approach is more suitable for monorepos.

Though, env vars still work, so it's just a matter of convenience.

[jfly]

But, I have a lot of small repos, so it's not feasible to update everything

I still don't get it. Where does your treefmt.withConfig code live? How do other people contribute to your projects? How do you set up CI for these projects?

[knightpp]

But, I have a lot of small repos, so it's not feasible to update everything

I still don't get it. Where does your treefmt.withConfig code live? How do other people contribute to your projects? How do you set up CI for these projects?

Imagine there's a repo with all Nix configs which provides all required tools to work on any project. Then there are hundreds of active repositories. So, as you can imagine one global Nix configuration covers almost everything (including treefmt.WithConfig), except some edge cases where tweaks to the config are inevitable.

[jfly]

This sounds problematic to me. Imagine you upgrade this central repo to use a newer version of some formatter, or to start enforcing formatting for some filetype that previously didn't have formatting enforce. All of a sudden, all your repos are broken because they're formatted using the old version of the formatter.

Sorry if I'm sounding contentious here. I trust that you get a lot of useful work done with your setup. The point I'm trying to make is that there are other issues you'll run into if your repos aren't "self contained".