Strange, Undocumented Properties Out in the Wild about grunt-contrib-jshint HOT 4 CLOSED

It looks like these are user-specified properties to pass to watchers, and are not parsed in your scripts. I'm going to close this issue because this isn't really a problem you guys should address as much as a problem with people polluting config objects. I wonder if this is a common thing to do? If there's anything you feel would be valuable to someone else who might stumble across this issue feel free to post about it!

from grunt-contrib-jshint.

Those are targets which can be named however the author chooses. This allows for more fine grained control as the jshint task in that Gruntfile.js can be ran like grunt jshint:gruntfile or grunt jshint:lib_test. options can be set at the task level (applies to all targets) or target level, as only applies to that target.

from grunt-contrib-jshint.

Gotcha, thanks for the link. When you call grunt jshint:gruntfile, does it run jshint with all of the jshint options but only on that source? It's not very clear from looking at the source that the JS hint task will just kick in on those. For example, could someone do something like:

jshint: {
      options: {
        node : true,
        curly: true,
        eqeqeq: true,
        immed: true,
        latedef: true,
        newcap: true,
        noarg: true,
        sub: true,
        undef: true,
        unused: true,
        boss: true,
        eqnull: true,
        globals: {}
      },
      gruntfile: {
        src: 'Gruntfile.js',
        options: {
           eqeqeq: false
        }
      }
}

with the task grunt jshint:gruntfile, and the one option would override the default options but the rest would cascade? I'm imagining these things to be more like sub-tasks. But from the looks of the usage I'm seeing, the user is basically just storing properties in an arbitrary namespace that really has nothing to do with the jshint task?

from grunt-contrib-jshint.

Yes the options work as you've indicated. I wouldn't necessarily call targets "sub-tasks". They're more akin to make targets in a traditional makefile. A good example, imo, is a dev and prod setup. You may only want to target certain files (and options) per task based on the operation you're doing.

from grunt-contrib-jshint.