Open mgrebenets opened 5 years ago
@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.
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.
@nicklockwood Any plans for this?
@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.
@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 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.
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:
All rules are disabled by default.
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.
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.
@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.
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.
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.
Hi
This is a feature request for supporting alternative config format. While plain text works, it lacks a few features, such as:
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:
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:
Another benefit would being able to share same exclude lists between tools like SwiftFormat and SwiftLint.