Extends and disabling rules (and severities) about stylelint

[MoOx]

If a power user is building on top a recommended styleguide then they don't need to worry about maintaining that part of the rules configuration.

+1 for this

Does anyone have a strong opinion on this?

Not sure it will be that complex to handle with numbers.

I don't think we need to resolve this now though as this issue shouldn't affect how we write the rules themselves, right? Is it something that can be dealt with entirely in the stylelint index.js?

If we need to choose warning vs errors we will need somewhere to adjust the behavior of a plugin. Maybe we can pass severity has an option if > 0 then save the severity in the postcss message. Then consumers that will read results (stylelint index.js?) will behave differently depending on severities.

That said, I am not sure how we make this works with simple plugin like postcss-log-warnings.
Initially I asked for an api with log level built in, but @ai kind of refused this (I say "kind of" because object containing messages is called "messages" but public API is using the working "warnings" only, so not sure what we can do with that api).

[jeddy3]

I am not sure how we make this works with simple plugin like postcss-log-warnings.

Shall we hold off on this issue for now then, and continue to focus on getting the simplest/temporary version working (a postcss plugin that can be used with postcss-log-warnings to log warnings to console)?

I'll keep this issue open so anyone else can contribute to the discussion, or if they fancy having a go at coding a solution.

[MoOx]

So, shall we hold off on this issue for now then, and continue to focus on getting the simplest/temporary version working

lgtm

[davidtheclark]

Am I oversimplifying in thinking that the difference between 1 and 2 is just the exit code if lint problems are reported (1 = exit code success, 0; 2 = exit code error, 1+)?

Just trying to understand.

I think it makes sense that stylelint couldn't force postcss-log-warnings to exit with an error or not an error. When the user configures logWarnings, they get to decide whether warnings matter. Stylelint would need its own reporter to force exit codes, I think.

[ai]

I think that error exit code should be generated by stylelint too.

I think we can have a API link in gulp-eslint:

postcss()
    .use( stylelint() )
    .use( logWarnings() )
    .use( stylelint.failOnError() )

[davidtheclark]

Nice idea @ai

[MoOx]

We should not handle exit code, only runners should ! (ref http://eslint.org/docs/rules/no-process-exit )
At the end, I think stylelint tool will not be just a postcss plugin so we wont have to rely on postcss-log-warnings.
Also we have to think to future integrations with stuff like webpack that provide api to emit errors/warnings.

[davidtheclark]

Right, so stylelint would have its own "runner" as ESLint has its own default runner, right? You could use it or you could use something else.

[MoOx]

ESLint has a bin runner & a node api. For my concern I use the webpack loader. So we can have multiples way to use the linter depending on the worflow, env etc. So we have to provide a way without just using exit() but messages with severity flags.

[davidtheclark]

So you're saying we'd have a severity flag on the message, then

• the stylelint CLI (bin runner) would know how to deal with them
• specialized stylelint plugins for webpack, gulp, whatever, would know how to deal with them
• non-specialized things that log PostCSS warning/error like gulp-postcss etc. or postcss-log-warnings would just print warnings but not interpret the severity flag.

Are we on the same page?

[MoOx]

Yes I think it's a solution.

non-specialized things that log PostCSS warning/error like gulp-postcss etc. or postcss-log-warnings would just print warnings but not interpret the severity flag.

We could enhance those to make them better :)

[ai]

Why we can't just throw a error from stylelint.failOnError?

[MoOx]

Error is one severity level, we might have info, warnings or errors (recoverable error, so throwing is not useful).

[codemakerlive]

As it stands I think it's very important that a user can select whether a rule is:

• Severe enough to be an error in their production (val 2)
• Simply warn to allow them to review their code but not halt production (1)
• Not appropriate to their coding style so can be turned off (0)

For stylelint output:

• stdout would be an object with exit code and output string. Whatever works with PostCSS/stylelint directly handles this object.
• Fully passed lint is 0 (success), doesn't really need an output string - perhaps just "SUCCESS"
• Warning exit code is 0 (success) with information for all warnings encountered provided in the output string.
• Error exit occurs on first error encountered in code where rule is assigned at error-level by the user. The error code returned is 1 (general error), with information on the error encountered in the exit string.
• Filesystem errors and other exceptional errors could throw (some npm tools do this, though I don't believe it's tidy as exceptions shouldn't really cross API/tool boundaries) or could return non-0 error, perhaps numerically coded as per the following CLI tools:
  http://gsp.com/cgi-bin/man.cgi?section=3&topic=sysexits
  http://www.tldp.org/LDP/abs/html/exitcodes.html
  http://www.linuxjournal.com/article/10844
• Crucially, only errors return non-0. That way when output object from stylelint (the runner that handles it) is piped to another tool it does not break/halt that piping if user-specified rule at warning level is encountered.
• To be of any use the descriptive "output" string must include line number in the source code where it occurred (columns not so important - to the point it's not really worth the burden of implementation)

Not sure why you need an info level? Just warnings or errors - with code identifier and string output. The tool is not really for conversation beyond result code and descriptive string. Any tool warnings can just be treated like rule warnings. Any tool errors like rule errors (but with different output return code).

[stela5]

I agree with @codemakerlive -- only errors return non-0

It would be nice to have a .stylelintrc-ish config for quiet mode that only reports errors, not warnings

There are a number of projects that import CSS frameworks which may not have strict CSS syntax standards and therefore will throw a lot of warnings that will bury your own code mistakes.

[davidtheclark]

Good idea @stela5. I made an issue for it: #383 .

[jeddy3]

@codemakerlive Thanks for your original input btw. I believe a lot of your suggestions have been incorporated into #380

[davidtheclark]

Done in #380