Refmt configuration file

[rusty-key]

Since it is possible to configure max output line length for refmt, can we consider support for configuration file similar to .ocamlformat?

I understand that refmt is supposed to be opinionated non-configurable formatter. But having one configurable option is not really different from having a lot of them. Developers still need to somehow share this configuration, and right now it is something that is hard or impossible to achieve.

What do you think?

[Lupus]

Real world story from one department in a large company: engineers and managers started endless arguing regarding python formatters and corresponding configurations. It was ended by agreeing to use single not-so-popular formatter that did not have any configuration.

Opinionated non-configurable formatter is a must in modern software engineering. Golang is a great example of how opinionated non-configurable things make everything highly consistent and coherent, and save time which would otherwise be wasted on arguing and agreeing upon some local standards.

[rusty-key]

@Lupus, my suggestion is about providing uniformed way of sharing one option that is already configurable. I am not suggesting extending configurability of refmt

[TheSpyder]

having one configurable option is not really different from having a lot of them

It's actually very different, this does read as suggesting additional configurability, but putting that aside I agree having a file for this would be awesome.

I don't like needing to use vscode settings to enforce the line length, which means the IDE integration needs a setting for it too.

[jordwalke]

What tool would supposedly read such a config file format? Refmt itself? Or build tooling such as dune?

[jordwalke]

Thanks for starting the discussion. I thumbs upped it and thumbs downed it because it's complicated. Doesn't it seem overkill to have a config file just for one item?
What tool would support the configuration? Refmt, or build tooling? If refmt, then it's something that might require a lot of integration with a lot of editor tooling to get right (such as all the vim plugins etc). If it's a pseudo-supported/encouraged config file format that isn't handled by refmt directly, then it wouldn't happen in the editor, and dune would be the one to handle it and there's very little downside in terms of editor tooling burden. But on the other hand it means peoples' editor plugins would not necessarily respect it and then their build time reformatting will keep getting out of sync with their in-editor tooling. So it seems that if it is done - it has to be supported by refmt. And in that case, what's the protocol for determining the config location?

If it is a good idea in the first place, it seems a package.json would be the best place to put such a config because peoples' directories are already littered with tons of config files especially when they have a native project that has .install, .opam, package.json, dune-project, dune files all at the root. But if it's in the package.json, which .json file should it use? (That's not that hard of a question to answer, but just needs to be specified - they can have a test.json, package.json, release.json - all different esy configs).

[TheSpyder]

I assumed it would be supported by refmt directly, to avoid all the out-of-sync issues - which to be clear we already experience today. I have both an editor config setting and a script to make sure nobody checks in without running refmt. They both need to specify the width.

I'm not fussed whether it's a .refmt file or a special case in a known config file.

[jordwalke]

Would it climb to the root of the file system upon every refmt invocation starting with the file path? What if it's coming from stdin, would it use the pwd? If someone wants to specify a concrete proposal for where it should live and how it's resolved, and get some consensus around it, it will make people much more willing to send a PR because they will see it is more likely to get merged.

[TheSpyder]

The suggestions to have a line length setting in ocaml-lsp and vscode-ocaml-platform seem unlikely to happen. It would really help to have a config file; I've had to use some pretty weird hacks to wrap refmt in a shell script and set the line length there.

[rgrinberg]

The suggestions to have a line length setting in ocaml-lsp and vscode-ocaml-platform seem unlikely to happen.

It is also a poor suggestion. It would exclude all other editors and those using RLS, or merlin directly.

[jchavarri]

What tool would support the configuration? Refmt, or build tooling?

Maybe refmt could just follow what ocamlformat is doing. We can split the problem in two parts, as each of them is quite involved on its own:

• First, support some config file .refmt in the same vein as .ocamlformat, that climbs up dir tree to find more configs, relevant code in ocamlformat: https://github.com/ocaml-ppx/ocamlformat/blob/39c6197eb2a8f27d7fd64035f5fb6a52a598845c/lib/bin_conf/File_system.ml#L56-L109
• Second, integrate with ocaml-lsp through some RPC protocol. Maybe for this it can reuse parts of ocamlformat, see https://github.com/ocaml-ppx/ocamlformat/tree/39c6197eb2a8f27d7fd64035f5fb6a52a598845c/lib-rpc

[jchavarri]

it seems a package.json would be the best place to put such a config

I think it'd be optimal to have a specific config file like .refmt because Reason projects can be installed with opam or nix as well.