sds
Allow rules to be configured via comments
While we currently allow rules to be enabled and disabled via comments, there are some cases where it would be nice to simply change some rule configuration via comments.
For instance, if you are using SelectorDepth for the first time, you might want to enforce a max depth of 3 for all new code but still allow higher depths for old code. If you could configure this rule via a comment, you would be able to achieve this pretty easily and naturally by adding configuration comments to the necessary files.
I'm initially opposed to this because of the complexity involved and my belief that you can't do this properly in the general case.
The moment you allow linters to be configured on a line-by-line basis, you need to run each potential configuration of the linter against the file (i.e. each line which sets a custom configuration requires a separate run), since it may be nonsensical for a linter to "switch configuration" in the middle of the lint run. You can imagine a linter which scans the entire file in order to decide whether a lint is reported: it makes no sense to allow its configuration to be changed mid-run.
No doubt there are many linters where this concept would work fine. My concern is that this doesn't work in the general case, so I'm hesitant to introduce it as that could be a source of confusion/difficulty.
I do think there is room for better support of different configurations based on the directory of the file being linted. We've avoided this in scss-lint because of the implementation complexity and my (highly opinionated) belief that this was also a bad idea for any development project. The reason being that it requires significant cognitive overhead to remember all the different configurations for different directories in a project. I feel that the most you should be able to customize on a directory-by-directory basis is whether or not a linter is enabled, which is supported by the single configuration file model SCSS-Lint currently supports. (and let me be clear: I totally understand there could be valid reasons to want different configurations, I just haven't been presented with a strong-enough case)
Have you seen this feature (specifically line-by-line configuration changes) in other projects? How does it behave for those projects? Do you think such a feature has wide potential for adoption, or is it more of a "power-user" feature that benefits a minority of use cases?
Have you seen this feature (specifically line-by-line configuration changes) in other projects? How does it behave for those projects?
ESLint has this, which is where I got the idea from.
Do you think such a feature has wide potential for adoption, or is it more of a "power-user" feature that benefits a minority of use cases?
Gosh, it's really hard to say.
Interesting. So does ESLint actually let you change the configuration part way through the file? Or do these comments only work at the top of the file?
My lack of familiarity with the kind of problems ESLint reports makes it difficult for me to see how they would implement this. If all their checks were simple syntax-related checks, this would make sense–but changing the configuration of a linter that needs to scan the entire file during the course of the lint run? That seems riddled with problems, unless it's a "use at your own risk" kind of situation.
To provide a concrete example of what I'm talking about, consider the PrivateNamingConvention linter that was just added. This linter needs to scan the entire file in order to find all declarations and uses. Changing the prefix option with a comment in the middle of the file introduces problems here, because the linter has already processed much of the file using the original prefix, but now we're changing the prefix, meaning we might miss some uses/declarations for the old prefix.
If ESLint's answer to this is to only let you specify this custom configuration comment at the top of the file, then I'm more open to this idea. Reading their documentation doesn't suggest that's the case, however.
Yeah, you are right. The ESLint comment options apply to the whole file, no matter where they appear in the file (with the last one taking precedence), which I think is good enough for my use-case.