Make warnings evident in different workflows

[tomek-he-him]

For this LESS input:

.some-selector {
  &:extend(.non-existent-selector);
  other: rules;
}

we only see a warning when we explicitly run:

$ lessc input.less output.css
extend ' .non-existent-selector' has no matches

There are a couple of problems with this:

1. When we do it any other way – like $ lessc input.less, or programmatically with node – there's no warning at all.
2. Even so it doesn't look like a warning. From what the stdout says we have no idea if he build has succeeded.

Why it's important:

there's no way to spot the failure other than manually scanning through the output.

– from #2459

For the record:

Non-matched extends produce warnings now (the only problem you won't see a warning when compiling with anything other then lessc in.less out.css but that's the warning implementation itself to be polished further).

As for error or warning thing itself it might be questionable (rationale behind warnings is that you may have some generic code that intentionally uses not always matching extends), but this actually to be solved if we'll go a canonical compiler route and have multiple warning levels controlled by cli-options including one for warning -> error (i.e. "warning implementation polishing" again).
– from #2459

[tomek-he-him]

AD 1. From what I can see, upon running $ lessc input.less stderr is empty. How about using that for displaying CLI errors and warnings?

AD 1. I use gulp-less for building my project. It'd be great if that logged something when it sees a warning. Perhaps less.render(input, callback) could pass some special kind of error to the callback when it wants to communicate a warning? So that tools like gulp-less can pick it up.

[seven-phases-max]

At first glance I'd rather suggest to put warnings as comments into the generated CSS itself (i.e. stdout instead of stderr... Otherwise (if I'm not mistaken) it will broke stuff using lessc input.less > output.css).

[SomMeri]

lessc input.less > output.css redirects only stdout. If you want to redirect both stderr and stdout you have to do lessc input.less &> output.css.

I think it is more correct to put errors and warnings into stderr, it would allow scripts to check for warnings and errors easily. lessc will be often run by tools instead of manually and having to parse output.css for warnings and errors is ugly.

[seven-phases-max]

Well, that's not just input.less > output.css. There're many editors/IDEs that capture output of external tools and in most it's just imposible to get both stderr and stdout (for instance the one I use won't log stderr if errcode = 0), i.e. since warnings are not errors, spamming stderr w/o an actual error may break common "piping stuff" conventions in many ways.

having to parse output.css for warnings and errors is ugly.

Many tools interpret any output in stderr as a error and stop.

---

To be more specific my idea is not to replace stderr with comments in CSS everywhere but only use it if no output file specified. In other words, we should have a way to see warnings somehow with just lessc input.less (maybe not by default but with certain cli-option) but can't use stderr for that since this will break tools that assume lessc input.less outputs either a error or valid CSS.

[SomMeri]

@seven-phases-max That is a good point. Out of curiosity, which tools do that?

I got curious and tested gcc, python and javac compilers on windows. All three print both errors and warnings into stderr. They use exit code 1 when they encounter error and exit code 0 when they encounter warnings only.

That does not mean we have to do it the same way, just that it is the standard way. If too many tools in js/css word tend to misinterpret streams, it might make sense to go with them. But, I still think it is their bug and they should fix it :).

[lukeapage]

I think we should print to stderr and not assume -s when printing to stdout. Commands using less can always pass -s to shut less up.

gulp/grunt should use this http://lesscss.org/usage/#programmatic-usage-getting-access-to-the-log
please raise an issue with them to add support.