Swiftformat: Alternative config format

[mgrebenets]

Hi

This is a feature request for supporting alternative config format.
While plain text works, it lacks a few features, such as:

• Detect syntax errors, e.g. if I type incorrect flag or add a space where there shouldn't be a space, etc.
• Syntax highlight when editing
• No out of the box support to parse config

As an example, using YAML would offer all of the above and more.

One other example where a yaml config would be better (in my opinion), is having a long list of exclude paths.

A mangled example:

--exclude archive,buck-out,build,Carthage,Doc,Docs,Documentation,path/xxxx/xxxX/Abcd/Xyz/Generated,path/xxxx/xxxX/Abcd/Storyboards,path/xxxx/xxxX/Abcd/Zyz/XYZ/Generated,path/xxxx/Pods,path/yyy/App/abcd/Generated,path/yyy/App/abcd/Templates,path/yyy/App/abcd/View/Ignore,path/yyy/abcd/Sources/Ignore,path/yyy/abcd/Sources/Generated/UIStoryboard+SwiftGen.swift,path/yyy/Pods,path,path,Pods,sonar-reports,test

It's not easy to review in pull requests or edit without wrapping it first (both may be subjective criteria).

the same example in yaml:

exclude:
  - archive
  - buck-out
  - build
  - Carthage
  - Doc
  - Docs
  - Documentation
  - path/xxxx/xxxX/Abcd/Xyz/Generated
  - path/xxxx/xxxX/Abcd/Storyboards
  - path/xxxx/xxxX/Abcd/Zyz/XYZ/Generated
  - path/xxxx/Pods
  - path/yyy/App/abcd/Generated
  - path/yyy/App/abcd/Templates
  - path/yyy/App/abcd/View/Ignore
  - path/yyy/abcd/Sources/Ignore
  - path/yyy/abcd/Sources/Generated/UIStoryboard+SwiftGen.swift
  - path/yyy/Pods
  - path
  - path
  - Pods
  - sonar-reports
  - test

Another benefit would being able to share same exclude lists between tools like SwiftFormat and SwiftLint.

[specialfor]

@mgrebenets I think the same would be great for long list of --enable or --disable rules.
I have explictly added all enabled and disabled rules in .swiftformat file, because, as for me, it looks more obvious what rules are used and what are not.

[nicklockwood]

I agree that yml seems to be the standard. I think it would be confusing to have two formats, but I'll consider migrating to yml in future.

[dogo]

@nicklockwood Any plans for this?

[nicklockwood]

@dogo I assume this relates to your other query? I don't think the problem is due to not using yaml, as spaces in paths are supported with the existing format.

[nicklockwood]

@mgrebenets, @specialfor FYI it's now possible to split your rules onto separate lines, as follows:

#excludes 
--exclude some/path
--exclude some/other/path

#rules 
--enable foo
--enable bar
--disable baz

[dogo]

@dogo I assume this relates to your other query? I don't think the problem is due to not using YAML, as spaces in paths are supported with the existing format.

@nicklockwood It's not related, I found this issue when I was searching for any issue with whitespace, but this issue/enhancement its a great feature for improving the readability and detect syntax errors.

[sindresorhus]

I think the current way the config is structured is a bit confusing. I have a lot of experience with linter config from the JavaScript ecosystem. For example, it's not immediately clear what rules are enabled/disabled by default.

Here's how I would do it:

1. All rules are disabled by default.

2. Only one way to enable/disable individual rules:

rules:
  attributes: true
  todo: false

This format makes it possible to support config inheritance in the future, as individual entries in the rules dictionary can override the parent config.

1. Recommended preset, which would be what the current defaults are.

presets:
  builtin: true

I understand that 1 is quite a breaking change, so a less breaking change would be to do only 2 and 3, and then I could just disable the builtin preset myself.

[nicklockwood]

@sindresorhus probably a good idea to open this as its own issue, since it doesn't really relate to the question of yaml vs other formats.

FWIW, I think you can get the behaviour you want by using the --rules option to just specify the rules you would like to opt-in to.

[sindresorhus]

probably a good idea to open this as its own issue, since it doesn't really relate to the question of yaml vs other formats.

Which part? Assume you mean 1, because the other things are related to the YAML config format.

[nicklockwood]

Which part? Assume you mean 1, because the other things are related to the YAML config format.

Having a single way to disable/enable rules, and having presets are both suggestions that can be implemented independently of the config file format.