jshint / jshint / 2296 / 1
100%
master: 100%

DEFAULT BRANCH: master
Ran
Files 13
Run time 2s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 97.502% (+0.02%) from 97.481%
2296.1

push

travis-ci

Mike Pennisi 
[[FIX]] Do not enable `newcap` within strict mode

Since the first public release of JSLint (ca120a7), this codebase has
automatically enabled the `newcap` option for all strict mode code:

    function use_strict() {
        if (nexttoken.value === 'use strict') {
            advance();
            advance(';');
            strict_mode = true;
            option.newcap = true;
            option.undef = true;
            return true;
        } else {
            return false;
        }
    }

Commit 8de8247 unified the way JSHint detects and enforces strict mode
across contexts. Among other modifications, it included the following
change:

    - if (state.tokens.curr.value === "use strict") {
    + if (state.isStrict()) {
        if (!state.option["(explicitNewcap)"]) {
          state.option.newcap = true;
        }
        state.option.undef = true;
      }

This change introduced a regression: it enables the `newcap` option for
class bodies and ES2015 module code as well.

Because ES5's strict mode and the warnings enabled by the `newcap`
option are orthogonal (and because as a stylistic concern, the `newcap`
is deprecated) correct the regression by relaxing the behavior for all
cases--do not automatically enable `newcap` when entering strict mode,
for whatever reason.

This change is backward-compatible because it will not cause JSHint to
produce new warnings. It corrects undocumented and surprising behavior,
so it should be considered a bug fix (despite the age of the bug in
question).

3942 of 4043 relevant lines covered (97.5%)

3147.1 hits per line

Source Files on job 2296.1