Options to control swift-format

[MahdiBM]

There should be some options to control swift-format that is bundled with the toolchains.
I'm not sure how this'll play with the fact that the formatter is called by sourcekit-lsp, not directly by the vscode extension. Perhaps @ahoppen can enlighten me.

Some possible options:

• Option to completely disable swift-format.
• Custom swift-format executable path.
• Custom arguments to be passed to swift-format.
• Custom paths to search for .swift-format.
• Option to disable formatting on projects with certain conditions.
  • For example is there is no Package.swift or if there is no .swift-format file.

[ahoppen]

Synced to Apple’s issue tracker as rdar://139514618

[ahoppen]

• Option to completely disable swift-format.

What would be the benefit of that? If you don’t want it, you can choose to not invoke formatting. Or am I missing something?

• Custom swift-format executable path.

What would be the use case? I would prefer to not add configuration options unless we know that they solve real-world problems.

• Custom arguments to be passed to swift-format.

Which arguments would you pass here?

• Custom paths to search for .swift-format.

What would be the reason to not have .swift-format in your project root?

• Option to disable formatting on projects with certain conditions.
  • For example is there is no Package.swift or if there is no .swift-format file.

Similar here, when would this be useful?

[MahdiBM]

I would prefer to not add configuration options unless we know that they solve real-world problems.

@ahoppen right. I didn't make these up, I just looked at what options the vknabel formatter extension gives and assumed there are reasons for existence of those options.

What would be the benefit of that? If you don’t want it, you can choose to not invoke formatting. Or am I missing something?

I'm not 100% sure how it plays in VSCode but someone might want to use one of the vknabel extensions and format their Swift files, just not use the swift-extension's formatter. But then you can choose another formatter in VSCode UI so i can get behind not having this option for now.

Custom swift-format executable path.

swift-format is bundled with the toolchains which means it's not updated too frequently. Maybe someone wants to use an updated version of swift-format.

Custom arguments to be passed to swift-format.

Not sure what I'd pass here ... I guess in swift-format's case there may not be too many options to modify (yet?). But I can see this being useful in the future. Maybe there is an experimental flag or something added?
Again, I just grabbed these from the other extension.

Custom paths to search for .swift-format.

I personally don't mind it but the root directory can get pretty crowded with 20 different config files sitting there in the bigger projects. VSCode does show the ./hidden files too in the navigator, unlike Xcode.

Option to disable formatting on projects with certain conditions.

This should be helpful to avoid swift-format running with its default configuration just because no config exists.
Not sure if that's already the behavior and if sourcekit-lsp already requires a config file to exist.
It's been a while i personally haven't used any projects missing a Package.swift, so not sure about that ... I can get behind not having the option for Package.swift, if noone else has a usecase.

[MahdiBM]

For me personally it would be important to be able to disable/enable swift-format's "Format Document" behavior when no .swift-format exists, but still keep Format Selection and on-type formatting.

Because if a project has .swift-format then we're all good, but if it doesn't, I still want to use swift-format, just not to format the whole file, or to accidentally trigger format-on-save, mostly to make sure I don't format whole-files of repos i don't maintain which don't support swift-format.

It could be valuable to have options to disable each of on-type, selection or whole-document formattings only by themselves, when there is no .swift-format.

[ahoppen]

Thanks for your detailed reply. I don’t think there are any concrete needs for the options you mentioned in the original post and I’d prefer to not add options just for the sake of having more options. If there are use cases that are enabled by the options, I’m happy to add them.

For me personally it would be important to be able to disable/enable swift-format's "Format Document" behavior when no .swift-format exists, but still keep Format Selection and on-type formatting.

I think this option makes sense to add.

[MahdiBM]

If we want to do minimal options for now unless a need appears, then I want to mention that i think Custom swift-format executable path. is also a relatively important one.
It won't be hard to have an outdated swift-format.

We currently use mint to make sure we use the same SwiftFormat version. We'd want to do the same for swift-format as well. Otherwise there can be formatting mismatches and the CI could fail while the local (outdated) formatter has done its best.

This has already happened to us with different SwiftFormat versions. Not hard to happen, specially as swift-format gains more and more options that can subtly conflict in weird scenarios.