Configuration via Command Line Flags?

[SDGGiesbrecht]

(Related to #1207, but more specific.)

Is there a way to specify configuration options with command line flags, and still have them merged with any extant .swiftlint.yml files, or at least some other way of achieving a similar effect?

The reason I want to do this is that I am writing a project manager for Swift, Workspace, that stitches together and helps automate various tools like SwiftLint.

There are several configuration options that are necessary for SwiftLint to cooperate with the other tools, such as excluding the Swift Package Manager’s Packages folder. Right now I do this by writing a .swiftlint.yml file to the project root before running SwiftLint and deleting the file afterward. The problem with the current set‐up is that when a user wants to customize SwiftLint further by writing his or her own .swiftlint.yml, he or she must figure out what those basic necessary options are and include them manually.

I am looking for a way of specifying such options without touching any .swiftlint.yml files, so that they properly take effect no matter what, and at the same time the user can fully customize SwiftLint.

[marcelofabri]

There's no way to do this currently.

[jpsim]

Maybe Workspace could ship with its own .swiftlint.yml file, stored in the app bundle maybe, and then the invocation of SwiftLint could specify that special config?

Although from what I can tell, Workspace is mostly intended to be built via SPM, which doesn't build bundles but static executables, so you could write the config file to ~/Library/Application Support/Workspace/.swiftlint.yml?

[SDGGiesbrecht]

Maybe Workspace could ship with its own .swiftlint.yml file, stored in the app bundle maybe, and then the invocation of SwiftLint could specify that special config?

@jpsim, That would work, provided:

• the hierarchy of .swiftlint.yml files is merged, not overridden (Merge nested configurations rather than replacing them outright #676)
• The (flag‐)specified(?) .swiftlint.yml could be treated as a parent to the .swiftlint.yml in the project root, and not an override.

---

...from what I can tell, Workspace is mostly intended to be built via SPM...

Actually, for now it installs its own Git repository within ~/.Workspace (a Linux‐safe path) so that it can use resources and update itself easily.

[jpsim]

Yes, you're correct on all counts there.

[SDGGiesbrecht]

I’m closing this because its various aspects are each covered in other issues.