Use the first .scss-lint.yml configuration file found in the current working directory or one of its ancestors

[webgefrickel]

I understand how the configuration files work at the moment (.scss-lint-files by --config flag >> CWD >> ~), and no merging. I just ran into an 'issue' in a very large project with different teams regarding the configuration of the linter - because everybody wanted to do sth. just a little bit different :/ (tabs vs. spaces etc.)
The solution then was, that every team got their own config-file, with their own customizations. This resulted in a lot of duplicated code in the .scss-lint.yaml-files (and lots of those files as well). Adding or changing rules in the future would thus be quite tedious, because it has to be done in lots of files...

I know that this is more a political issue and should be solved by just sticking to one default standard for all teams, but could you consider sth. like eslint's configuration cascade? http://eslint.org/docs/user-guide/configuring#configuration-cascading-and-hierarchy

The idea here: every file is being checked by using 'the closest' .scss-lint.yaml file - if none in the current dir, move to the parent and so on - and as a last resort ~/.scss-lint.yaml. This way I could configure a 'sane default', and then let the teams just add their custom rules on top.

Would this be possible at all, or do you even think that this would be a bad idea?

[Anahkiasen]

because everybody wanted to do sth. just a little bit different :/

Wouldn't that go, like, against the purpose of having a linter in the first place?

[webgefrickel]

I know this is more a political issue. But regarding different teams: inside the team everybody sticks to their rules it is not really against the purpose of a linter (and they quite like it) — but the rules between the different teams don't match. Political stuff like tabs vs. spaces aside e.g. one team wants to be 'more strict' than the others, disallowing extend or extending from classes and making use of the new BemDepth-Linter. I know that those are edge-cases, just some food for thought :)

[srawlins]

So that its not a breaking change for everyone, it could be implemented as a feature that requires cascade: true at the top-level of a .scss-lint.yaml, in order to merge with a deeper one.

[sds]

scss-lint used to support "inheriting" configurations but removed it in 56cbbd2. Pasting the commit message here because I think it's informative about why:

Remove inherit_from and per-directory configuration support

These two features were created very early in scss-lint's history, and
were largely a result of trying to emulating the rubocop project's
configuration system.

Over time, it's become clear that the configuration system is the most
complex part of scss-lint, both in implementation as well as tests. At
the core of this complexity is the ability to "inherit" configuration
files via inherit_from, and to load directory-specific configurations
based on the location of an SCSS file.

I think supporting these features encourages messier and harder to
understand configurations. After seeing scss-lint used in the wild,
it's clear that a majority of users only have an .scss-lint.yml file
in the root-level directory of their repositories, and furthermore those
who actually have custom configurations in subdirectories could easily
merge those configurations into the root config.

By allowing configurations to be located anywhere in the repository, the
developer now has to search multiple files in order to reconcile their
configuration, rather than consult a single file. While this may mean
the single file is larger, we're not talking thousands of lines of
configuration.

Removing these two features free us to simplify the configuration system
significantly, and opens up some other refactoring opportunities.

Thus I'm not terribly interested in re-introducing this functionality unless the implementor completely refactors the configuration system to be better-decoupled and well-tested.

[webgefrickel]

Ah, I see. Since I am not a ruby guy I can't be the implementor :/ Regarding 56cbbd2 I see why one would not be interested in re-introducing more code for such edge cases — and for all other projects I've worked on one .scss-lint file always was enough, so I totally understand your reasoning.

But (of course there is a but ;)) — another idea: would it be easier to (re-)introduce sth. that does not merge the configs, but at least tries to find the next config? E.g. I have a large project with lots of git-submodules with scss-files. I don't want to introduce one scss-lint-config for each submodule, rather one in the root-project-folder that is used even if my CWD is the submodule-folder (in the likes of: check for .scss-lint.yaml -> not there? -> check parent folder and so on, if one is found just use it, and don't merge with previous configs...). Now it just uses the .scss-lint-config from my home-directory and not the one from the project-root-folder.

Do you understand what I am trying to achieve? Sorry for my english and thanks for all your time.

[sds]

I think I understand what you're asking, @webgefrickel. You're requesting that scss-lint support ascending directories (starting from the current working directory) until it finds an .scss-lint.yml file, and using the first one it finds.

I would be open to adding such functionality, although it's always a bit surprising to accidentally be using the .scss-lint.yml from an ancestor directory when you forgot to create an .scss-lint.yml in your current directory.

[webgefrickel]

I understand your concern about "ccidentally be using the .scss-lint.yml from an ancestor directory" — maybe we could just print out a line when checking on the CLI, sth. like:

Using /Users/dude/Sites/test/.scss-lint.yaml as configuration

If there is anything I can help with, let me know.

[hail2u]

I think finding .scss-lint.yml up to the project root directory (.git, .hg, package.json, or something else exists) is good choise.

[di5abled]

Why don't add an extends option to explicit define which other settings should be used (as baseline)?
ESLint does this and it is really practical: http://eslint.org/docs/user-guide/configuring.html#extending-configuration-files

For example, we have one node_module where we store our default eslint settings (and more) and use this as baseline for each of our projects via the extends option.

[bensaufley]

My team has adopted eslint, haml-lint, and scss-lint. Both eslint and haml-lint support cascading up from the current directory until a config is found. This is a very helpful feature to share configs across multiple projects (say, within the same team/ directory) without defining at the root, and would be very helpful if implemented in scss-lint as well.

[mmzoo]

This is a very helpful feature to share configs across multiple projects (say, within the same team/ directory)

This is our use-case as well. We have a one-scss-config-to-rule-them-all but there is no good way for us to use it in our projects.

Because that would involve copy-pasting the content into every project. Or at least forcing all developers to keep it in sync with their $HOME directory (symlinking it there). And we'd have to teach our CI to do the same thing.

I propose an inherit_from directive just like rubocop has. So we can have a config file in every repository but it inherits from the global one.

[md5]

I'm not a fan of the idea of searching parent directories to implicitly inherit behavior, but the main use I've seen of inherit_from in Rubocop is to put things into .rubocop_todo.yml. I actually find this relatively useful since it's more self-documenting than adding comments in the main .rubocop.yml when cops are being disabled in a pinch due to time pressures.

One other feature of Rubocop that I'd like to point out is the ability to inherit configurations from another gem using inherit_gem (added in rubocop/rubocop#2270). We use this functionality in my team to centralize default Rubocop configuration into a shared gem, making it easy to roll out changes across all of our projects. I would love to see similar functionality in scss-lint.