Request: Command line output in JSON format #593

Open
bdkjones opened this Issue Dec 11, 2012 · 59 comments
@bdkjones

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."
file: "/path/to/some/file.sass"
line: 34
character: 19
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

@chriscoyier

+1

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!

@unr

+1

@demogar

+1

@steve228uk

👍

@yeeyang

+1

@andimal

+1

@banunn

+1

@Meroje

👍

@ghost

+1

@baudoin

+1

@b00y0h

+1

@28Bytes

+1

@marcaube

+10 ... why not

@chriseppstein
Sass member

Please stop adding +1s. We will review this issue on it's merits, not popularity.

@mgrn0

+2

@petehotchkiss

+1... Chris, surely popularity is a measure of merrit.

@nex3

The +1s are indeed not helpful.

I do like this idea, though.

@nex3

The json-output branch has the beginning of support for that. A lot more is needed:

  • There's no error-specific metadata, such as the line offset for syntax errors. There is some metadata for warnings, though.
  • There's no documentation.
  • There are no tests for the JSON formats of the warnings with metadata.
  • Warnings don't have Sass backtraces (see also #605).
@gajus

+1

@bdkjones

Any idea if/when this might make it into the official release? It would really be handy!

@nex3

Unfortunately, it's not especially high-priority. It might be a good thing for someone other than Chris or myself to work on.

@Hirvesh

+one

@eriwen

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 :)

@chriscoyier

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

@bdkjones
@nex3

@eriwen The json-output branch should be pretty straightforward to merge with the latest master. That's definitely the best place to start.

@eriwen

@nex3 Thanks for the info. Couple questions:

  • I see that the sass_backtrace in JSON has file and line number info for SyntaxErrors. Is there other metadata we need for SyntaxErrors?
  • Are you also thinking we need JSON handling/metadata on other errors?
  • I'm not yet sure how to add sass backtraces to warnings. Do you think this is necessary for the first implementation or can you give me any pointers? Thanks.
@bdkjones

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!

@eriwen

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.

@chriscoyier

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).

@bdkjones

@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:

errorLine
errorColumn
errorNumber (the lints return many, many errors)
errorLevel (can be warn or error, depending on severity of problem)
etc.

Where possible, I would adopt the naming conventions from JSHint/JSLint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment