ability to ignore all rules for specific lines

[miripiruni]

// my innocent JS code
...

/*jscs: false*/
// evil uncontrolled awful JS code
...
/*jscs: true*/

// again my beautifull JS code
...

Inside /*jscs: false*/ ... /*jscs: true*/ jscs will ignore all code.

What do you think?

[mdevils]

Reasonable. But due to Syntax Tree Structure, I have no good ideas how to implement. But you can try :)

[kaero]

May be useful: https://code.google.com/p/esprima/issues/detail?id=197

[kaero]

@mdevils I has reviewed this issue and has found that comments' array contains locations of the comments, so we can found all comments for BlockStatements, parse these comments and set temporary options for checks.

[mdevils]

Yeah, I see. It is possible. The thing is that I can't find good, easy solution for implementing this in the current rule behavior.

[mdevils]

Got an easy implementation idea.

I suggest these regions: /* jscs: off */ -- /* jscs: on */.

[kaero]

Am i right that you propose to turn on/off jscs at all for region?

[mdevils]

Yep.

[Krinkle]

See also #223 (requests inline configuration in general, as opposed to just disabling everything).

This seems especially needed in case one is dealing with an upstream interface. For example, enforcing camel case identifiers and properties but encountering something like unicodeSpec.Regional_Indicator.

I'm referencing #102 as this is somewhat of a regression when coming from JSHint as migrating from camelcase: true to requireCamelCaseOrUpperCaseIdentifiers: true is problematic if /*jshint camelcase:false */ doesn't have an equivelent.

[kangax]

Ran into this well when referencing third-party "G_vmlCanvasManager" (from excanvas.js), which doesn't satisfy camelcase, otherwise enforced in our project.

+1

[kangax]

Another way to allow for 3rd-party exceptions like G_vmlCanvasManager is by having a whitelist in config; similar to JSHint's "globals":

{
  requireCamelCaseOrUpperCaseIdentifiers: true,
  identifierCaseExceptions: [ 'G_vmlCanvasManager', '...' ]
}

or even:

{
  requireCamelCaseOrUpperCaseIdentifiers: [ 'G_vmlCanvasManager', '...' ]
}

..although this might be too confusing.

[nschonni]

@kangax I like the approach, but maybe

requireCamelCaseOrUpperCaseIdentifiers: {
    ignore: [ 'G_vmlCanvasManager', '...' ]
}

The first way would require a second rule, and the second is a little confusing since it seems like you are trying to enforce the camel casing on the exceptions.

[NickHeiner]

This seems especially needed in case one is dealing with an upstream interface. For example, enforcing camel case identifiers and properties but encountering something like unicodeSpec.Regional_Indicator.

I have this issue as well. I think it would be nicer to just be able to turn off specific rules (or jscs checking entirely) for certain regions - having to put this stuff in the config requires the developer to be aware of more places in the code at once.

[donaldpipowitch]

+1

I need this for calls to a different library.

[dentuzhik]

Why not to comply with jshint in such case?
From jshint docs

// Code here will be linted with JSHint.
/* jshint ignore:start */
// Code here will be linted with ignored by JSHint.
/* jshint ignore:end */

ignoreThis(); // jshint ignore:line

Would be much better to have a common api between similar tools.

/* jscs ignore:start */
/* jscs ignore:end */
// jscs ignore:line

[Kienz]

#20 (comment) +1

[MattiSG]

+1 for interaction with external library

[laurelnaiad]

+1 -- would like to have some way to ignore ala /* jshint ignore:start/end */

[dsuckau]

I need this too, for the use of an external library.... I prefer the inline comments like in JSHint and ESLint too.

[mikesherov]

This is fixed in fa5527a and will be release with version 1.6.0!

[MattiSG]

Great, thanks! :)

Le 3 août 2014 à 02:02, Mike Sherov notifications@github.com a écrit :

This is fixed in fa5527a and will be release with version 1.6.0!

—
Reply to this email directly or view it on GitHub.

[kangax]

@mikesherov thanks! any idea when you'll be tagging 1.6.0?

[markelog]

any idea when you'll be tagging 1.6.0?

Should happen on this week