Loading ...
Sorry, an error occurred while loading the content.

overriding properties settings

Expand Messages
  • cheesox
    DC - Thanks for your ongoing efforts maintaining jslint. There s a conflict between the options specified in the call to JSLINT(), and the options specified in
    Message 1 of 1 , Aug 23, 2011
    • 0 Attachment
      DC - Thanks for your ongoing efforts maintaining jslint.

      There's a conflict between the options specified in the call to JSLINT(), and the options specified in the source code of the .js module.

      I append some WSH-specific logic to jslint.js, to allow me to run jslint from the Windows command line, or as a flymake process within emacs on Windows. It's available at


      I then used jslint-for-wsh.js to analyze jslint-for-wsh.js , and what I found is that specifying { properties: false } in the function call to JSLINT() gets overridden if there is a /*properties directive in the source module.

      I think the properties list is just a giant list of "approved names" that could be applied to any object at all. Not a very precise tool, but that is neither here nor there.

      When I ran JSLINT with {windows: true} it did not barf on WScript, which is nice, but it did barf on WScript.Arguments and WScript.StdErr, etc. - Unexpected /*property*/. To avoid that, I suppose I could add Arguments and StdErr to the list of approved property names, but I'm not sure how useful that would be, because those names should be used on just one object, ever. I'd hate to see any other object use 'Arguments' as a property name.

      So, easy solution, just pass an option object of {windows: true, properties: false} , right?

      No. That doesn't work because of the conflict I described earlier. After invoking JSLINT(), my desired options are accepted, but then the option.properties value gets forced to true by do_properties() as jslint scans the source.

      I don't know the right thing to do here, for when the option object conflicts with what is in the source code, but I do know that it was impossible for me to turn off the properties warnings that appeared on jslint-for-wsh.js without modifying jslint code. which I don't wanna do.

      It would be nice to have some documented, supported way to specify how to resolve conflicts. Maybe it's a third optional argument to JSLINT -I'm imagining a boolean, true implies that options applied on the call to JSLINT should take precedence over options defined in the source.

      The way I fixed it: I modified do_properties(). removed

      option.properties = true;

      and replaced it with

      option.properties = (typeof option.properties === 'boolean') ?
      option.properties : true;

      ...which implies that the option.properties passed to JSLINT() will never be overridden by the presence of a /*properties directive.

    Your message has been successfully submitted and would be delivered to recipients shortly.