fluid-project / fluid-lint-all

Consolidated linting logic free from any particular build technology
BSD 3-Clause "New" or "Revised" License
0 stars 5 forks source link

stylelint cannot be configured #28

Closed amb26 closed 2 years ago

amb26 commented 3 years ago

Contrary to the other plugins, stylelint seems to ignore both literal options as well as any local config file.

I have written in .fluidlintallrc.json

    "stylelint": {
        "options": {
            "rules": {
                "order/properties-alphabetical-order": null
            }
        }
    }

as per the docs but this option is ignored. Also, I have written a local .stylelintrc.json file with the following contents

{
    "rules": {
        "order/properties-alphabetical-order": null
    }
}

and it is ignored. In fact, the file is not read at all, since if I make it syntactically invalid, stylelint does not complain. This is different to the behaviour with respect to .eslintrc.json

the-t-in-rtf commented 3 years ago

I ran into the same thing this morning trying to improve the code coverage for stylelint. You have to additionally nest your rules in a config entry (there are other top-level configuration options other than rules). Stylelint complains about invalid rules, but seemingly does not complain about improperly nested material or even bogus entries. I could add my own checks for this, but I'd basically have to keep that up-to-date with their options. I could add a warning for the specific behaviour of passing rules at the wrong level if that seems enough.

amb26 commented 3 years ago

I've also written this:

    "stylelint": {
        "options": {
            "config": {
                "rules": {
                    "order/properties-alphabetical-order": false
                }
            }
        }
    }

This for some reason produces no CSS errors at all - even though there were some indentation errors in the mix before. Also, would it be possible to have the local .stylelintrc.json file processed?

amb26 commented 3 years ago

I also put an invalid rule inside the "rules" block above and there was no report from stylelint

the-t-in-rtf commented 2 years ago

I added a test fixture for this as part of GH-29. Here's the bad rule from the tests:

https://github.com/fluid-project/fluid-lint-all/blob/main/.fluidlintallrc-invalid-stylelint-option.json#L37

That results in output like:

13:38:04.957:  Errors returned by stylelint:
13:38:04.957:  
13:38:04.958:    - tests/fixtures/css/bad.css:
13:38:04.958:      Unexpected option value "bad value" for rule "string-no-newline"
13:38:04.958:  
13:38:04.958:    - tests/fixtures/css/good.css:
13:38:04.958:      Unexpected option value "bad value" for rule "string-no-newline"
13:38:04.958:  
13:38:04.958:    - tests/fixtures/scss/bad.scss:
13:38:04.958:      Unexpected option value "bad value" for rule "string-no-newline"
13:38:04.958:  
13:38:04.958:    - tests/fixtures/scss/good.scss:
13:38:04.958:      Unexpected option value "bad value" for rule "string-no-newline"
13:38:04.958:  

I had to do it that way because the configuration errors are reported per file. I might be able to come up with something more robust, but was hoping that would be adequate.

the-t-in-rtf commented 2 years ago

In later research I discovered that specifying config completely destroys any rules brought in by the default configFile. See #44 for an example of overlaying custom options via a separate configuration file.

the-t-in-rtf commented 2 years ago

I believe this was addressed in #44?

amb26 commented 2 years ago

Thanks, this is all good now!