Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 409781

Summary: JSLint support does not handle options that are available at jslint.com
Product: [ECD] Orion Reporter: Mike Wilson <Mike_Wilson>
Component: ClientAssignee: Project Inbox <orion.client-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: mamacdon, simon_kaegi
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Mac OS X   
Whiteboard:

Description Mike Wilson CLA 2013-06-03 15:46:25 EDT 
Iwan Winoto said this...
"
If I parse my code at the JSLint site (http://www.jslint.com/) it also complains. However at the bottom of the JSLint parser, there are options to let the parser know the code is Node as well as setting other options (variables starting with '_', turn off warnings about unused parameters, etc).

Another way of setting those options is with a comment at the top of the code:
    /*jslint node: true, nomen: true, unparam: true, sloppy: true */

This comment tells JSLint that its node.js code (so it accepts keywords like 'require', 'process', etc).
With this directive, the validator at jslint.com clears my code. However, JazzHub Orion still complains about my code even with this directive.

While I can clear validation errors with /*global ...*/ directive, I'd rather not have to fill it with all the node.js core objects. The validator should recognise node.js code (either be cause I have a node directive, or from the structure of the project - i.e. inclusion of a package.json file) and not complain about node.js core objects.

So I think there is still something wrong with the JSLint in JazzHub Orion.
"
Is there a reason why we don't support these options? Can we?
Comment 1 Mark Macdonald CLA 2013-06-03 22:31:45 EDT 
> Is there a reason why we don't support these options? Can we?

We are running an ancient version of JSLint that doesn't have the Node options. It needs to be upgraded.

I investigated this once before and gave up (see bug 368207), because JSLint had become too pedantic: several previously minor coding problems were treated as fatal parser-terminating errors. The usability was very poor.

So we can (and should) do this, but we need to figure out how to make newer JSLints behave similar to the version we currently have, which I think strikes a pretty good balance in terms of strictness.
Comment 2 John Arthorne CLA 2015-05-05 14:51:48 EDT 
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see:

https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html