I would like Sass's command line utility to optionally return errors in a JSON format. I envision something like this:
errorMessage: "This is the reason Sass failed to compile."
code: "This is the line of Sass code containing the error"
stacktrace: "junk here"
The reason I ask is that having the output in a parseable format allows infinitely better integration of Sass in third-party applications that want to do custom formatting of the Sass compiler's return messages.
I strongly recommend that you adopt JSON over alternatives such as CSV and XML. JSON is cleaner, smaller, more easily read by humans (in case they need to do so), faster to parse in almost every instance and is quickly replacing XML as the default on the modern web.
/cc @nex3 @chriseppstein
I really like the idea of third party apps being able to do more with the error data. Instead of having to parse text themselves. In a perfect world all preprocessors would standardize on an error output format!
+10 ... why not
Please stop adding +1s. We will review this issue on it's merits, not popularity.
+1... Chris, surely popularity is a measure of merrit.
The +1s are indeed not helpful.
I do like this idea, though.
The json-output branch has the beginning of support for that. A lot more is needed:
Any idea if/when this might make it into the official release? It would really be handy!
Unfortunately, it's not especially high-priority. It might be a good thing for someone other than Chris or myself to work on.
Hey guys... I know Ruby and I ❤️ Sass, so I'd like to take a crack at this. However, I was wondering if I still ought to start from the json-output branch. It seems like there is some work there toward the feature, but the branch itself seems to have diverged significantly from stable.
@nex3 @chriseppstein In your opinion, would it be worth it to make a new branch from stable and pull in the bits of work related only to JSON output? I really, really want to avoid an ugly merge. Thanks :)
For use-case motivation, I'm working on inline error messaging in CodePen for Sass and I'm having to do RegEx stuff (thx @chriseppstein) on the error strings to get the numbers I need to do it. http://cl.ly/PZ7s
@eriwen The json-output branch should be pretty straightforward to merge with the latest master. That's definitely the best place to start.
Add tests for JSON warnings with metadata for sass/sass#593
@nex3 Thanks for the info. Couple questions:
I would be totally happy without the backtrace. In fact, that's a huge part of why I'm looking to do custom error formatting: to get rid of the backtrace!
Add filename, line, and mixin metadata to JSON error output for sass/…
Draft of json-err documentation for sass/sass#593
I'm not convinced that the metadata for syntax errors is quite what the maintainers were thinking, so that should be closely reviewed. I am having a hard time writing a test for the JSON output from SyntaxErrors, that is still pending.
Looking forward to your feedback, guys.
I think it would be cool to publish the JSON format in a kinda neutral place at some point, so we can point every other preprocessor maintainer to it. "Hey guys, look at this format, we could standardize error output based on this and the world will rejoice."
e.g. naming like error-line and error-message rather than anything specific to Sass (unless it's really specific to Sass, like the backtrace).
@chriscoyier Could not agree more.
I would suggest looking at the names for JSLint and JSHint error objects, as they do a pretty good job. They're generally camelCase, like this:
errorNumber (the lints return many, many errors)
errorLevel (can be warn or error, depending on severity of problem)
Where possible, I would adopt the naming conventions from JSHint/JSLint.