Renamed plugin configuration parameter #696
Conversation
As trivial as this is, this change is to prevent a conflict with running the plugin with the `--configuration` parameter which is recognised and parsed by the Swift Package Manager and expects to be either `debug` or `release`. The replacement of `--swift-format-configuration` is verbose, but other choices looked too ambiguous or confusing whereas this is at least clear as to what the parameter is doing.
There was a problem hiding this comment.
I don’t think we can change this as tooling might depend on the parameter being named --configuration. sourcekit-lsp, for example, does: https://github.com/apple/sourcekit-lsp/blob/cbb569320831d2aa48d251cadf63199c8f7ce840/Sources/SourceKitLSP/Swift/DocumentFormatting.swift#L185
We could add swift-format-configuration as another spelling of the same option, but I think we should keep --configuration as well.
|
sourcekit-lsp is invoking the Separately, the macOS CI is failing but I'm not sure why—I don't see anything relevant there, the failure appears to be a TSAN issue. |
|
As @allevato said, existing tooling that is using |
|
Ah, OK. Sorry, I missed the distinction between the binary and the plugin. LGTM then |
All good. I still think it’s a bit cringey to have to do this, but unless SPM changes its behaviour to ignore command line options after the module name, this is the only way around it. Might be worth raising to avoid things like this in the future. |
As trivial as this is, this change is to prevent a conflict with running the plugin with the
--configurationparameter which is recognised and parsed by the Swift Package Manager and expects to be eitherdebugorrelease.The replacement of
--swift-format-configurationis verbose, but other choices looked too ambiguous or confusing whereas this is at least clear as to what the parameter is doing.resolves #668