Support jshint style JSON format for .csslintrc file

[jzaefferer]

This came up when adding .csslintrc file support to grunt-contrib-csslint: gruntjs/grunt-contrib-csslint#6

Turns out the format the csslint expects is CLI options in a file. It would be great to instead support a format equivalent to what jshint supports in its .jshintrc file, matching what CSSLint also expects when using it programmatically.

As an usage example of the preferred format, here's a commit in jQuery UI where we moved from options to .csslintrc file: jquery/jquery-ui@39a2f46

Since csslint is still not on a 1.x.x release, I suggest to change the format instead of trying to support both.

Also related is this ticket for SublimeLinter, to add support for .csslintrc files: SublimeLinter/SublimeLinter#386

If this is acceptable, I'll try to put together a pull request.

/cc @tkellen @scottgonzalez

[nzakas]

Thanks for the feedback. Can you explain a little more about why you feel
the format should be changed? I'm having trouble understanding how this
would be an improvement (assuming you're still letting CSS Lint pickup the
file - I'm not sure what the difference would be).

-N

On Fri, Mar 15, 2013 at 9:31 AM, Jörn Zaefferer notifications@github.comwrote:

This came up when adding .csslintrc file support to grunt-contrib-csslint:
gruntjs/grunt-contrib-csslint#6gruntjs/grunt-contrib-csslint#6

Turns out the format the csslint expects is CLI options in a file. It
would be great to instead support a format equivalent to what jshint
supports in its .jshintrc file, matching what CSSLint also expects when
using it programmatically.

As an usage example of the preferred format, here's a commit in jQuery UI
where we moved from options to .csslintrc file: jquery/jquery-ui@39a2f46jquery/jquery-ui@39a2f46

Since csslint is still not on a 1.x.x release, I suggest to change the
format instead of trying to support both.

Also related is this ticket for SublimeLinter, to add support for
.csslintrc files: SublimeLinter/SublimeLinter#386SublimeLinter/SublimeLinter#386

/cc @tkellen https://github.com/tkellen @scottgonzalezhttps://github.com/scottgonzalez

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/359
.

---

Nicholas C. Zakas
@SlickNet

Author, Professional JavaScript for Web Developers
Buy it at Amazon.com:
http://www.amazon.com/Professional-JavaScript-Developers-Nicholas-Zakas/dp/1118026691/ref=sr_1_3

[asciidisco]

👍 I think it would improve the readability of the file a lot.
Also it would be nice if the linting tools that I use in my toolchain would be as similar as possible when it comes down to configuration.

[nzakas]

Readability is a very personal thing - I actually find JSON structures
quite difficult to read and prefer not to use them for configuration
information. I prefer using a format that has a much simpler syntax (and is
therefore harder to mess up).

I'm also concerned that not having a direct mapping to the CLI options
would be confusing to people.

I'm not completely against providing a JSON option, I just need to be
convinced that this is either causing a problem in its current state. Of
course, if someone were to go off and build it as an additional option (I
don't want to replace what we have right now), I may change my tune.

On Fri, Mar 15, 2013 at 10:25 AM, Sebastian Golasch <
notifications@github.com> wrote:

[image: 👍] I think it would improve the readability of the file a lot.
Also it would be nice if the linting tools that I use in my toolchain
would be as similar as possible when it comes down to configuration.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/359#issuecomment-14973839
.

---

Nicholas C. Zakas
@SlickNet

Author, Professional JavaScript for Web Developers
Buy it at Amazon.com:
http://www.amazon.com/Professional-JavaScript-Developers-Nicholas-Zakas/dp/1118026691/ref=sr_1_3

[scottgonzalez]

I don't really care if JSON is the choice, but just dumping raw command line options into a file isn't very friendly. Would you prefer INI?

If you're willing to accept a pull request that adds JSON support on top of the existing support, I'll happily put that together.

[nschonni]

Maybe .csslintrc.json for the alternate format

[jzaefferer]

@scottgonzalez this sounds like @nzakas would accept such a PR:

Of course, if someone were to go off and build it as an additional option (I don't want to replace what we have right now), I may change my tune.

Is detecting JSON as simple as looking for a "{" as the first character? Or would you do a JSON.parse call and see if that doesn't throw up?

As for the motivation here (what Nicholas was asking about in his initial reply): The main motivation is consistency with similar tools, in this case jshint. Having a somewhat comparable format would make it much easier to other tools to build on top, in this case grunt plugins and SublimeLinter. Just read the JSON file and forward the result to the underlying tool.

An alternative approach might be to expose the CLI-config-parser in the programmatic CSSLint API, so that the grunt csslint plugin can use that. But since that isn't really documented anywhere I didn't bother with that direction in the first place. Is that something you'd be more interested in fixing?

[nzakas]

I guess I'm a little confused by this thread. I thought putting the command
line options into a file would be the simplest and easiest way to get this
functionality - after all, what can be easier to understand than doing the
same thing in a different place?

I'm also not sure I understand the consistency/ease of use argument. Can
you explain why the current format makes it harder to do integrations with
Grunt, Sublime, or anything else?

At the moment, I'm completely overextended and don't have time to do any
fixes, but I'm more than happy to review any proposed changes that someone
wants to create.

On Mon, Mar 18, 2013 at 7:57 AM, Jörn Zaefferer notifications@github.comwrote:

@scottgonzalez https://github.com/scottgonzalez this sounds like @nzakashttps://github.com/nzakaswould accept such a PR:

Of course, if someone were to go off and build it as an additional option
(I don't want to replace what we have right now), I may change my tune.

Is detecting JSON as simple as looking for a "{" as the first character?
Or would you do a JSON.parse call and see if that doesn't throw up?

As for the motivation here (what Nicholas was asking about in his initial
reply): The main motivation is consistency with similar tools, in this case
jshint. Having a somewhat comparable format would make it much easier to
other tools to build on top, in this case grunt plugins and SublimeLinter.
Just read the JSON file and forward the result to the underlying tool.

An alternative approach might be to expose the CLI-config-parser in the
programmatic CSSLint API, so that the grunt csslint plugin can use that.
But since that isn't really documented anywhere I didn't bother with that
direction in the first place. Is that something you'd be more interested in
fixing?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/359#issuecomment-15059271
.

---

Nicholas C. Zakas
@SlickNet

Author, Professional JavaScript for Web Developers
Buy it at Amazon.com:
http://www.amazon.com/Professional-JavaScript-Developers-Nicholas-Zakas/dp/1118026691/ref=sr_1_3

[scottgonzalez]

My motivation for this change isn't about easier integrations, but just readability. In my opinion, long lists of command line arguments are hard to read and manage. JSON/YAML/INI are all much nicer to work with.

I'll put together a patch to support the current format and JSON in the existing rc file.

[tkellen]

I guess I'm a little confused by this thread. I thought putting the command
line options into a file would be the simplest and easiest way to get this
functionality - after all, what can be easier to understand than doing the
same thing in a different place?

The easiest way to inflate options from a file into a JS object is JSON.parse. You're not parsing command line options when you read a configuration file, you're reading a configuration file. From an interoperability standpoint, JSON is the clear winner here--that's what it's made for. Thanks for taking the initiative on this @scottgonzalez!

[cowboy]

Presumably, inside of csslint, there is some code that parses a .csslintrc file containing CLI arguments into a map of options for csslint to use. If that parsing logic were exposed, tools that wrap the csslint lib could pass in arbitrary .csslintrc file contents, get a map of options back, and then run the csslint lib with the options it expects.

[nzakas]

I caution people about this all the time: readability is personal and
unique. As I said earlier in the thread, I find JSON configuration files
harder to read. So let's move this discussion in a more productive
direction.

If the need is to get configuration options into a JavaScript object, then
that's something different. If you're telling me that you're using the
CSSLint API directly and not going through the command line interface, then
that's something different as well. Is that what you're doing?

As I said, I'm not against adding something, I'd just like to have a good
idea about why this is being requested other than it's a format someone
prefers. If there's trouble integrating with Grunt, I'd like to know what
that trouble is specifically. If there's trouble integrating with
SublimeLinter, then I'd like to know what that trouble is as well.

Without understanding the problem, I can't be sure if the suggestion of
adding JSON-based configuration actually solves it or not (or if there's
already a way to do what you want!). I'm asking for everyone's help here so
I can wrap my mind around this request.

On Mon, Mar 18, 2013 at 2:28 PM, Ben Alman notifications@github.com wrote:

Presumably, inside of csslint, there is some code that parses a .csslintrcfile containing CLI arguments into a map of options for csslint to use. If
that parsing logic were exposed, tools that wrap the csslint lib could pass
in arbitrary .csslintrc file contents, get a map of options back, and
then run the csslint lib with the options it expects.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/359#issuecomment-15083067
.

---

Nicholas C. Zakas
@SlickNet

Author, Professional JavaScript for Web Developers
Buy it at Amazon.com:
http://www.amazon.com/Professional-JavaScript-Developers-Nicholas-Zakas/dp/1118026691/ref=sr_1_3

[scottgonzalez]

It seems that many of us have different reasons for wanting this. @asciidisco stated he wants consistency with .jshintrc. @tkellen's main concern is simplicity in implementation for Grunt. My main concern is readability. Note that what I'm asking for isn't even the format that was implemented in grunt-contrib-csslint.

Here's what we currently have in jQuery UI (which is the custom format that Grunt supports):

{
    "adjoining-classes": false,
    "box-model": false,
    "compatible-vendor-prefixes": false,
    "duplicate-background-images": false,
    "import": false,
    "important": false,
    "outline-none": false,
    "overqualified-elements": false,
    "text-indent": false
}

This is, in my mind, a bit silly. It's a hash of rules, but all you can do is turn rules off (the equivalent of ignore, but with the added verbosity of having to explicitly set each value to false). This does provide consistency with .jshintrc, but I don't think consistency should be a driving factor here. They're different tools with different configs.

This is what a proper .csslintrc would look like:

--ignore=adjoining-classes,box-model,compatible-vendor-prefixes,duplicate-background-images,import,important,outline-none,overqualified-elements,text-indent

It's quite long and very cramped. I have a hard time reading it.

This is what I want to write:

{
    "ignore": [
        "adjoining-classes",
        "box-model",
        "compatible-vendor-prefixes",
        "duplicate-background-images",
        "import",
        "important",
        "outline-none",
        "overqualified-elements",
        "text-indent"
    ]
}

I'd even be fine with the standard command line format if whitespace was meaningless:

--ignore=
  adjoining-classes,
  box-model,
  compatible-vendor-prefixes,
  duplicate-background-images,
  import,
  important,
  outline-none,
  overqualified-elements,
  text-indent

At that point it starts to look like INI or YAML. I'd be ok with either of those (and I don't even like YAML).

The reason that I want JSON is because it's easy to work with, and in my opinion, easy to read.

I can't speak to what would make it easiest for SublimeLinter to integrate .csslintrc, but for Grunt, exposing the logic that the CLI uses to parse the options would suffice. Grunt wants to be as minimal as possible with its wrappers, so if it could say "Please parse this config file into something I can pass to csslint.verify()" that would be ideal.

---

With all of that being said, I already have an implementation that is very small and seems to work properly. However, the Contributing wiki page says "If you are submitting changes to the CLI, the changes must work in all three environments: Windows Script Host (WSH), Rhino, and Node.js. Please make sure to test your changes in each of these environments before submitting the pull request." So far, we can't even get CSSLint to run in WSH, so I haven't sent a pull request yet. However, the changes are minimal and the code is pretty basic. Perhaps you can verify that it works in WSH or maybe help @dmethvin track down why this fails for him in Windows 8 (the code that fails is in filterFiles(), not in the code I changed).

[nzakas]

I agree, in the case of having very long rulesets specified, that becomes
hard to read. I also agree it would be awesome to not worry about whtie
space in .csslintrc, and I think it's worth looking at that.

I'll try to take a look at the WSH issue - can one of you file a bug about
that?

On Mon, Mar 18, 2013 at 8:49 PM, Scott González notifications@github.comwrote:

It seems that many of us have different reasons for wanting this.
@asciidisco https://github.com/asciidisco stated he wants consistency
with .jshintrc. @tkellen https://github.com/tkellen's main concern is
simplicity in implementation for Grunt. My main concern is readability.
Note that what I'm asking for isn't even the format that was implemented in
grunt-contrib-csslint.

Here's what we currently have in jQuery UI (which is the custom format
that Grunt supports):

{
"adjoining-classes": false,
"box-model": false,
"compatible-vendor-prefixes": false,
"duplicate-background-images": false,
"import": false,
"important": false,
"outline-none": false,
"overqualified-elements": false,
"text-indent": false}

This is, in my mind, a bit silly. It's a hash of rules, but all you can do
is turn rules off (the equivalent of ignore, but with the added verbosity
of having to explicitly set each value to false). This does provide
consistency with .jshintrc, but I don't think consistency should be a
driving factor here. They're different tools with different configs.

This is what a proper .csslintrc would look like:

--ignore=adjoining-classes,box-model,compatible-vendor-prefixes,duplicate-background-images,import,important,outline-none,overqualified-elements,text-indent

It's quite long and very cramped. I have a hard time reading it.

This is what I want to write:

{
"ignore": [
"adjoining-classes",
"box-model",
"compatible-vendor-prefixes",
"duplicate-background-images",
"import",
"important",
"outline-none",
"overqualified-elements",
"text-indent"
]}

I'd even be fine with the standard command line format if whitespace was
meaningless:

--ignore=
adjoining-classes,
box-model,
compatible-vendor-prefixes,
duplicate-background-images,
import,
important,
outline-none,
overqualified-elements,
text-indent

At that point it starts to look like INI or YAML. I'd be ok with either of
those (and I don't even like YAML).

The reason that I want JSON is because it's easy to work with, and in
my opinion, easy to read.

I can't speak to what would make it easiest for SublimeLinter to integrate
.csslintrc, but for Grunt, exposing the logic that the CLI uses to parse
the options would suffice. Grunt wants to be as minimal as possible with
its wrappers, so if it could say "Please parse this config file into

something I can pass to csslint.verify()" that would be ideal.

With all of that being said, I already have an implementation that is very
small and seems to work properly. However, the Contributing wiki page says
"If you are submitting changes to the CLI, the changes must work in all
three environments: Windows Script Host (WSH), Rhino, and Node.js. Please
make sure to test your changes in each of these environments before
submitting the pull request." So far, we can't even get CSSLint to run in
WSH, so I haven't sent a pull request yet. However, the changes are
minimal https://github.com/scottgonzalez/csslint/compare/jsonrc and the
code is pretty basic. Perhaps you can verify that it works in WSH or maybe
help @dmethvin https://github.com/dmethvin track down why this fails
for him in Windows 8 (the code that fails is in filterFiles(), not in the
code I changed).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/359#issuecomment-15096096
.

---

Nicholas C. Zakas
@SlickNet

Author, Professional JavaScript for Web Developers
Buy it at Amazon.com:
http://www.amazon.com/Professional-JavaScript-Developers-Nicholas-Zakas/dp/1118026691/ref=sr_1_3

[scottgonzalez]

I filed #364 about WSH.

For ignoring whitespace, I think we can just strip whitespace completely and then split on --. Like I said, if support for that lands, I wouldn't have strong feelings for whether JSON support is added. My proposed JSON implementation would be compatible with this though, and I think a lot of users would prefer it. @nzakas How would you like to proceed?