Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

use_nested_configs: true ignores rule in "main" .swiftlint.yml #675

Closed
derpoliuk opened this issue May 27, 2016 · 7 comments
Closed

use_nested_configs: true ignores rule in "main" .swiftlint.yml #675

derpoliuk opened this issue May 27, 2016 · 7 comments
Labels
question Question or doubts that needs discussion and clarification. Can become a bug or proposal.

Comments

@derpoliuk
Copy link

I'm using SwiftLint 0.10.0

In my project I have 2 .swiftlint.yml: in MyProject/ and in MyProject/MyProjectTests/ folders.

# MyProject/.swiftlint.yml
line_length: 110
excluded:
 - Carthage
use_nested_configs: true
# MyProject/MyProjectTests/.swiftlint.yml
disabled_rules:
 - force_cast
 - force_try

And SwiftLint generates warnings in whole project, ignoring rule from first .swiftlint.yml:

Line Length Violation: Line should be 100 characters or less: currently 101 characters (line_length)
@jpsim
Copy link
Collaborator

jpsim commented May 27, 2016

We deprecated support for use_nested_configs in #527, so the value you're setting for that key in the config file is ignored.

Now nested configurations are always considered when present, but that still doesn't explain the behavior you're seeing. I'll try seeing if I can reproduce this.

@jpsim jpsim added the bug Unexpected and reproducible misbehavior. label May 27, 2016
@derpoliuk
Copy link
Author

@jpsim thanks for quick response, didn't know that use_nested_configs is deprecated.

@jpsim
Copy link
Collaborator

jpsim commented May 27, 2016

I can't reproduce this:

$ tree -a
.
├── .swiftlint.yml
├── test.swift
└── tests
    └── .swiftlint.yml
$ cat test.swift 
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
$ cat .swiftlint.yml 
line_length: 110
$ cat tests/.swiftlint.yml 
disabled_rules:
 - force_cast
 - force_try
$ swiftlint
Loading configuration from '.swiftlint.yml'
Linting Swift files in current working directory
Linting 'test.swift' (1/1)
Done linting! Found 0 violations, 0 serious in 1 file.
$ swiftlint version
0.10.0

The test.swift file has 110 / characters and the configuration from the root .swiftlint.yml file is applied so no violations are triggered.

What are you doing differently? Did I miss a step?

@jpsim
Copy link
Collaborator

jpsim commented May 27, 2016

didn't know that use_nested_configs is deprecated.

That's odd, since SwiftLint logs the following message when you include that key in a config file:

Support for 'use_nested_configs' has been deprecated and its value is now ignored. Nested configuration files are now always considered.

Are you sure you're using SwiftLint 0.10.0?

@derpoliuk
Copy link
Author

Are you sure you're using SwiftLint 0.10.0?

Yes, swiftlint version prints 0.10.0.

That's odd, since SwiftLint logs the following message when you include that key in a config file:

I didn't run it from command line, I'm using Xcode Run Script Phase for that.

What are you doing differently? Did I miss a step?

Finally I figured out what the difference: swiftlint generates this warnings for files in MyProjectTests folder. I didn't see it when I submitted this issue. Is it expected behavior with nested configs?

@jpsim
Copy link
Collaborator

jpsim commented May 27, 2016

Yes, nested configurations replace their parents. There's room for more intelligent merging of configurations, which we have commented in the code (link) but I can't find an issue that's currently tracking that.

I've filed #676 to track that improvement. If you're interested in contributing to SwiftLint, that'd be a great place to start!

Feel free to close this issue if you feel I've sufficiently addressed your questions 😄

@jpsim jpsim added question Question or doubts that needs discussion and clarification. Can become a bug or proposal. and removed bug Unexpected and reproducible misbehavior. labels May 27, 2016
@derpoliuk
Copy link
Author

@jpsim Thank you for your help!

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
question Question or doubts that needs discussion and clarification. Can become a bug or proposal.
Projects
None yet
Development

No branches or pull requests

2 participants