Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Consistent one-line CLI output (like jshint's) #88

Closed
oryband opened this Issue Jun 26, 2011 · 13 comments

Comments

Projects
None yet
4 participants

oryband commented Jun 26, 2011

Relates to #87, #89.

CSS Lint is awesome. It shouldn't be human-scannable only, but easy for programs as well.

Here's an example of jshint's output:

~/example/js$ jshint example.js 
example.js: line 10, col 10, Unexpected space after '('.
example.js: line 10, col 31, Expected '!==' and instead saw '!='.
example.js: line 10, col 45, Unexpected space after 'function'.
example.js: line 15, col 14, Missing semicolon.
example.js: line 16, col 10, Missing semicolon.
example.js: line 26, col 15, Unexpected space after '('.
example.js: line 27, col 18, Unexpected space after '('.

Now compare the above to CSS Lint's:

~/example/css$ csslint example.css


csslint: There are 110 errors and 236 warnings in /Users/ory/example/css/example.css.

...

/Users/example/css/example.css
27: error at line 153, col 1
Unexpected token '@' at line 153, char 1.
@-webkit-keyframes glow {

/Users/example/css/example.css
28: error at line 154, col 14
Expected COLON at line 154, character 14.
        from {

/Users/example/css/example.css
344: warning at line 491, col 13
Element (span.class_b) is overqualified, just use .class_b without element name.
.class_a span.class_b {

...

JSHint's is much easier to parse, and has remained consistent in all versions (probably because it's a fort of Crockford's JSLint).

Perhaps give a command-line option to output errors in this format? Without the extra "garbage" output e.g. the line where the error happened and the absolute path.

Contributor

nzakas commented Jun 26, 2011

That's certainly feasible. It's worth noting that CSS Lint's output matches the original Rhino output for JSLint.

I also need to come up with some tests to make sure the CLI output remains consistent.

Contributor

shinuza commented Jun 27, 2011

I agree with this, a --porcelain output would be nice. @nzakas, don't you think this is related to #86?

oryband commented Jun 27, 2011

@shinuza @nzakas: Yes, it's related, but I don't need the padding XML adds to this. Just print the errors in a one-form, one-liner format.

BTW, why --porcelain ? Does this word have a meaning I'm not aware of?

Contributor

shinuza commented Jun 27, 2011

@oryband: Well, the format plugins would allow us to do this is a cleaner fashion. There would be a "one-liner" formatter in respect to what you suggest.

Porcelain refers to git status --porcelain which prints out the status of your repo in a less verbose, easily parsable way. No need to call it that in CSSLint :)

oryband commented Jun 27, 2011

Thanks. :)

Member

eriwen commented Jul 12, 2011

Hope to make a pull request with this and additional documentation on Thursday.

Contributor

nzakas commented Jul 12, 2011

Awesome, looking forward to it!

@nzakas nzakas closed this in a4003b3 Jul 14, 2011

@nzakas nzakas added a commit that referenced this issue Jul 14, 2011

@nzakas nzakas Merge pull request #134 from eriwen/master
One-line output format (issue #88) and additional documentation
bd6494f

oryband commented Aug 7, 2011

This fix is still missing something. Please reopen this issue:

How can you diffrentiate between an error and a warning?

$ csslint --format=compact base.css

base.css: line 2, col 1, Expected RBRACE at line 2, col 1.
base.css: line 97, col 1, Missing vendor-prefixed CSS gradients for Webkit (Safari, Chrome), Internet Explorer 10+, Opera 11.1+.
base.css: line 35, col 3, Negative text-indent doesn't work well with RTL. If you use text-indent for image replacement explicitly set text-direction for that item to ltr.
base.css: line 57, col 1, Don't use IDs in selectors.
base.css: line 61, col 1, Don't use IDs in selectors.
Member

eriwen commented Aug 8, 2011

I think we'd need to decide that the fact that it's an error or warning is important enough to be shown in the compact format (I simply emulated the jshint format) and how to show it. Perhaps just a prefix of 'ERROR:' before the message (nothing for a warning)?

I think it'd also be valuable to sort the list by line number.

Thoughts?

oryband commented Aug 8, 2011

You should print the message type in any case, easier to parse.

E.g.:

Error: filename.css: bla bla
Warning: filename.css: bla bla
Contributor

nzakas commented Aug 8, 2011

Hi everyone,

This ticket has already been closed. If you have specific issues related to this feature, please open a new ticket to report it so that we can track appropriately.

oryband commented Aug 8, 2011

Right.

Opened a new issue. See #152 for further discussion.

oryband commented Aug 8, 2011

btw @eriwen, I believe the output is already ordered by error type, then by line number.

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