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.

[ahoppen]

I agree that having an option to point to a different swift-format executable would be useful.

[MartinLau7]

It would be great if custom format tool flags could be provided, similar to the options offered by the Go extension. However, I'm not sure whether this option configuration should be provided by sourcekit-lsp or by VSCode-Swift. Personally, I'm not very accustomed to the apple/swift-format tied to sourcekit-lsp; I usually prefer using nicklockwood/SwiftFormat.

[MahdiBM]

@MartinLau7 what flags would you want to provide that you can't now?

[MartinLau7]

@MahdiBM I believe I may have expressed myself incorrectly. What I am looking for is for sourcekit-lsp to provide options to switch between different formatting tools, such as apple/swift-format and nicklockwood/SwiftFormat.

As for flags, I hope apple/swift-format could provide a default flag to ignore line breaks, instead of requiring me to add // swift-format-ignore comments every time. This would be especially useful when I often declare base64 strings that exceed a certain length.

[MahdiBM]

As for flags, I hope apple/swift-format could provide a default flag to ignore line breaks,

Ah that's an issue for https://github.com/swiftlang/swift-format if it doesn't already exist.
I've also noticed a few annoying swift-format behaviors that are not possible to disable.

sourcekit-lsp to provide options to switch between different formatting tools

I'd like that as well to be honest.
@ahoppen do you see a path forward with that?
The only proper way i can think of is swift-format having the actual code to properly call each formatter tool? I'm not sure how we'll be able to make it pluggable, properly.
Maybe if the tools were expected to follow a certain format? Then anyone would be able to just use their tool of liking.
I can see this happening even now. SwiftFormat could add a subcommand which is compatible with how swift-format works, but it can get tricky with no docs or guarantees.

I can see that this adds a decent amount of complexity.

[ahoppen]

Yes, I think if we want to support arbitrary formatting tools, I think SourceKit-LSP should specify a command line option format that these formatting tools would need to follow – I haven’t checked but I wouldn’t be surprised if such a de-facto standard already exists. The tricky part is passing down options like indentation width (what we currently do here).