reid / node-jslint

The JavaScript Code Quality Tool — for Node.js.
http://jslint.com/
Other
491 stars 101 forks source link

"vars": true ignored in ~/.jslintrc #114

Closed mcandre closed 9 years ago

mcandre commented 9 years ago

I can successfully hide whitespace-related JSLint warnings with "white": true. But when I try to "vars": true, JSLint still shows Move 'var' declarations to the top of the function. warnings.

Configuration

https://github.com/mcandre/dotfiles/blob/master/.jslintrc

I am not using a project-local ./.jslintrc file.

System

$ specs npm:jslint node brew os
Specs:

specs 0.12
https://github.com/mcandre/specs#readme

npm list jslint
regenboog@0.0.2 /Users/apennebaker/Desktop/src/regenboog
└── jslint@0.8.1 

npm --version
2.6.0

node --version
v0.10.36

brew --version
0.9.5

system_profiler SPSoftwareDataType | grep 'System Version'
      System Version: OS X 10.10.2 (14C109)
smikes commented 9 years ago

This one is as designed by Crockford.

The vars option allows you to say "var a; var b;" instead of "var a, b;" but only at the top of a scope.

mcandre commented 9 years ago

My mistake.

Is there another configuration I can use to disable Move 'var' declarations to the top of the function. messages?

smikes commented 9 years ago

I don't believe so– this is one of the core design features of jslint as articulated in Crockford's "good parts" philosophy.

There are several unpalatable alternatives:

  1. Open a pr or issue request on the jslint repository or im the Google+ group. This is nearly certain to be rejected, in my experience.
  2. Privately fork jslint and cause 'node-jslint' to use your fork.
  3. Switch to a different linter such as "eslint" which is much more configurable but concomitantly less strict
  4. Use ES6 syntax such as "let" and "const" together with "es6": true — this is something I only recently became aware of and have not yet updated the node-jslint docs to reflect, which is that the latest jslint edition supports some es6 features.

Of course if you go es6 you will have to transpile or shim browser environments; since only you know the relative costs all I can do is suggest some options.

mcandre commented 9 years ago

I respect that JSLint was designed to check against this rule.

I'm asking for a boolean option to explicitly enable/disable this rule, as we do for other JSLint rules.

smikes commented 9 years ago

The boolean options that node-jslint supports are precisely the ones that jslint exposes. To add a new option would require a change to the jslint.js code, and it is the policy of this project to just deliver that code as-is, copied from the douglascrockford/jslint repository.

This project aims to provide a very small bridge for people who want to use the jslint linter, which many people feel is unreasonably strict, but some people prefer. The main alternative linter is eslint, which offers fine-grained control over warnings and errors.

I apologize, by the way, because when I was listing options above, I forgot to mention one more: you could change your code so all the var statements occur at the top of each function/scope. This is the style that jslint enforces, because it directly parallels the ES5 requirement about hoisting variable declarations and allowing references before the declaration.

Although I can't speculate about Crockford's motives for making var in the middle of a scope be a fatal error, I find that my own code is improved when I'm forced to see all the variables that I declare in a scope declared up top -- it motivates me to factor my code into smaller scopes with fewer variables in each. Your mileage may vary, of course.

mcandre commented 9 years ago

Thank you for explaining all of this to me. I will go upstream with my suggestions :)

smikes commented 9 years ago

Good luck! You might want to arm yourself beforehand by reading http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742 Javascript: the Good Parts

mcandre commented 9 years ago

Great resource, thanks!

From what I gather, ECMAScript is so hosed, that we have to try hard to code around it, using JSLint for ways to do things more safely.

smikes commented 9 years ago

It's not quite so bad. ES3 had some really rough parts, but the addition of strict mode in ES5 made a big difference. And ES6 is almost entirely good. The standards are here:

ES5: http://www.ecma-international.org/ecma-262/5.1/

ES6 (draft, unofficial): https://people.mozilla.org/~jorendorff/es6-draft.html

smikes commented 9 years ago

Out of scope.