Options.edition with the aboslute path didn't work about grunt-jslint HOT 7 CLOSED

Thanks for finding this. As you note, it is exactly a problem where the argument to loadJSLintFromPath() is shadowing the higher-level variable path, and then the call to path.resolve fails.

Fixed with latest grunt-jslint 1.1.11, please update to get the new version.

from grunt-jslint.

Could I have one more question? Why did the unit test pass with the two conflict variables?

from grunt-jslint.

function loadJSLintFromPath was not covered by the unit tests. And apparently jslint doesn't regard it as an error when one variable shadows another.

from grunt-jslint.

There was a case for loadJSLintFromPath loading a specific path in test/editions.js:

  jslint.loadJSLintFromPath('node_modules/jslint/lib/jslint-2013-08-26.js', function () {
    validate(file, opts, this.callback);
  }.bind(this));

},
'should not error': function (err, report) {
  assert.ifError(err);
},
'should be a correct edition': function (err, report) {
  assert.ok(jslint.edition === '2013-08-26');
},
'should have no violations': function (err, report) {
  assert.lengthOf(report, 0);
}

from grunt-jslint.

Yes. But the assertion in that case was testing for edition '2013-08-26' , which was also the edition loaded by the previous test case. So even if the call to loadJSLintFromPath failed, the test case wouldn't see it.

from grunt-jslint.

@novaez the custom edition stuff came in as a pr with horrible test coverage. we foolishly assumed it worked and published it without adding proper tests.

sorry for the bug, it's really quite embarrassing.

it should be fixed now, however. can you validate and close the issue?

from grunt-jslint.

@smikes Got it. Thanks!
@stephenmathieson I've got the latest version and it worked well. Thanks for all of your efforts.

from grunt-jslint.