[[FEAT]] Implement new option futurehostile
#2172
Conversation
| Reflect : false, | ||
| Symbol : false, | ||
| System : false | ||
| } |
There was a problem hiding this comment.
I definitely like this
nit: alphabetize lists like this as we go along—thanks!
There was a problem hiding this comment.
Should add:
5: {
JSON: false
}I don't think we need to go pre-ES3
There was a problem hiding this comment.
does the System object still exist? It was removed from the draft, and I thought it was going to be defined in a separate document but I haven't seen it anywhere if that happened
There was a problem hiding this comment.
Indeed, it was removed—I wonder if JSHint should claim domain over the separate spec as well?
jugglinmike
force-pushed
the
futurehostile
branch
from
c750f3f
to
0f1c8e0
Compare
1 similar comment
|
@rwaldron @caitp Thanks for the review! A couple things:
|
| }, | ||
| 5: { | ||
| JSON : false | ||
| }, |
There was a problem hiding this comment.
If you want to really correct, split up 3 into 1, 2 & 3... But that might be a bit much
There was a problem hiding this comment.
I do want to be really correct, but I agree that it would be overkill since (currently) there is no way to tell JSHint that you are operating in a pre-ES3 environment.
There was a problem hiding this comment.
Is this (numbered versions) convention going to confuse people if the year-based (eg ES2016™) scheme becomes widely known/popular?
There was a problem hiding this comment.
nevermind, I guess the numbers aren't really exposed via options or anything yet
There was a problem hiding this comment.
Is this (numbered versions) convention going to confuse people if the year-based (eg ES2016™) scheme becomes widely known/popular?
The spec will still have numbered editions, only the title will change. For example: "ECMAScript 2015 Language Specification" is the same document as "ECMA-262, 6th Edition"
|
@jugglinmike this needs a rebase |
|
@rwaldron Sure thing; should I squash while I'm at it? |
A recent change to JSHint included the ECMAScript 6 global identifiers in JSHint's collection of "predefined" variables. This disallowed the definition of those global values even in contexts that did not implement them. The intent of this change was to help users avoid bugs when migrating to the new version of the language. Re-using an existing warning mechanism caused confusion among many users [1][2][3] for two reasons: 1. The generated warning messages were somewhat misleading (i.e. the warning "Redefinition of 'Promise'." is inaccurate in ES5 environments) 2. The method of disabling the warnings did not accurately communicate the intent of the developer (i.e. setting `predef: -Promise` does not prompt the user to consider the user to consider if creating their own global variable named `Promise` is appropriate) A dedicated warning message more clearly describes the best practice that motivates this particular constraint on global variable names. An explicit option makes it less likely that users will disable this warning without understanding the motivation. Intoduce a new option, `futurehostile`, and dedicated warning message to better communicate the intent of restricting usage of future-reserved identifiers. [1] jshintGH-1747 redefinition of Promise (W079) [2] jshintGH-1995 ES6 globals are activated even though esnext=false [3] jshintGH-2171 Remove Set from the ECMAScript5 reserved words
|
Sure, that will be nice and clean |
jugglinmike
force-pushed
the
futurehostile
branch
from
0f1c8e0
to
da52aa0
Compare
|
@rwaldron All set |
[[FEAT]] Implement new option `futurehostile`
[[FEAT]] Implement new option `futurehostile`
[[FEAT]] Implement new option `futurehostile`
A recent change to JSHint included the ECMAScript 6 global identifiers
in JSHint's collection of "predefined" variables. This disallowed the
definition of those global values even in contexts that did not
implement them.
The intent of this change was to help users avoid bugs when migrating to
the new version of the language. Re-using an existing warning mechanism
caused confusion among many users [1][2][3] for two reasons:
warning "Redefinition of 'Promise'." is inaccurate in ES5
environments)
the intent of the developer (i.e. setting
predef: -Promisedoes notprompt the user to consider the user to consider if creating their
own global variable named
Promiseis appropriate)A dedicated warning message more clearly describes the best practice
that motivates this particular constraint on global variable names. An
explicit option makes it less likely that users will disable this
warning without understanding the motivation.
Intoduce a new option,
futurehostile, and dedicated warning message tobetter communicate the intent of restricting usage of future-reserved
identifiers.
[1] GH-1747 redefinition of Promise (W079)
[2] GH-1995 ES6 globals are activated even though esnext=false
[3] GH-2171 Remove Set from the ECMAScript5 reserved words