Renaming staticProvider to static causes a problem with JSLint #589

Closed
serby opened this Issue Mar 19, 2011 · 19 comments

Comments

Projects
None yet
10 participants
Contributor

serby commented Mar 19, 2011

Renaming staticProvider to static causes the following problem in JSLint

  Error:
  Problem at line 1 character 9: Expected an identifier and instead saw 'static' (a reserved word).

  express.static(__dirname + '/public');

  Implied global: express 1, __dirname 1
Owner

tj commented Mar 21, 2011

we had a discussion about this in the connect repo, it's not an issue at all, JSLint is just lame/outdated

tj closed this Mar 21, 2011

Contributor

serby commented Mar 21, 2011

We use JSLint as a quality assurance tool in Vim and with Jenkins. I'm sure we can configure it to allow static, but I don't like to disagree with Crockford.

Are there alternatives to JSLint that aren't so 'lame'?

Owner

tj commented Mar 21, 2011

it's not disagreeing with him, it's just that it is out of date. reserved words are fine when used as properties, not sure about configuring it

Owner

tj commented Mar 21, 2011

it's not disagreeing with him, it's just that it is out of date. reserved words are fine when used as properties, not sure about configuring it

Owner

tj commented Mar 24, 2011

yes, but they are fine when used as properties. I'm not discussing it lol JSLint sucks

A (ugly) workaround:

express["static"].apply(null, [__dirname + '/public']);

P.S.: And if you use good part options enabled there is also "__dirname" issue.
So after inserting "static" workaround, I have been using the following directives:
/*jslint node:true, nomen:false */

Owner

tj commented Mar 24, 2011

yea that will work. IMO the best solution is to not use jslint :D haha

maks commented Nov 30, 2011

I got annoyed by this too.

My solution using JSHint was to specify "es5:true" in the JSHint options and that stops JSHint from complaining about the use of 'static' as a property name. Looks like Crockfords JSLint also has the same es5 option.

Just leaving this here for future reference for the next person who trips over this using JS(H|L)int with their express app.

maks commented Nov 30, 2011

Not sure I'd consider the Lint tools broken - they are making
recommendations about possible errors, not compilers spitting out
syntax errors.

Maks.

On Wed, Nov 30, 2011 at 2:42 PM, TJ Holowaychuk
reply@reply.github.com
wrote:

dont look at me, im not the one with broken tools


Reply to this email directly or view it on GitHub:
visionmedia#589 (comment)

chjj commented Nov 30, 2011

This thread makes me proud to say I don't use jslint/jshint. Ever.

I'll let crockford explain why his creation is stupid:

Uh, one time I said intentional case-fallthroughs were good, but then another time I had a case fallthrough unintentionally, therefore, intentional case-fallthroughs are now bad.

If you didn't pick out the non-sequitur, read it again.

Owner

tj commented Nov 30, 2011

haha yeah totally, just a crutch that is usually incorrect, or only useful if you know very little javascript, which is fine it has its place but I'm certainly not renaming APIs for it

maks commented Nov 30, 2011

That's fine. I wasn't asking for any naming changes, I simply left my comment as a reference for anyone else who wanted a simple solution to the same issue that I and the person who originally opened the issue hit.

Owner

tj commented Nov 30, 2011

fair enough :D

Less ugly workaround:

express['static'](__dirname + '/public');

sebs commented Aug 5, 2012

es5 works quite fine for me. Using jslint as part of my build chain.

Kinda late to the party, but we should use path.join(__dirname, 'public') instead, because this can break on Windows.

Same issue with JSHint.

Member

rlidwka commented Sep 25, 2013

Same issue with JSHint.

Online checker on http://jshint.com/ works fine for me.

It's not really an issue anyway because JSHint should be configured properly in order to reduce false positives. If it still shows an error to you, report this bug to JSHint developers, because it is perfectly valid js code.

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