JSLint and JSHint will throw the "Expected an identifier and instead saw '{a}' (a reserved word)" error when they expect a reference to an identifier but finds a keyword that is reserved by the language. In the following example we attempt to declare a variable with the identifier default, which is a reserved word:
This error can also be thrown when JSLint or JSHint encounters an object property identifier that is a reserved word. This is valid in the ECMAScript 5 specification, but was not valid previously. In this example we attempt to declare an object property with the identifier default:
For the first example above, this error is raised to highlight a JavaScript syntax error. Your code will not run if you do not fix this error. Reserved words are special identifiers that are set aside by the ECMAScript specification for special use.
The specification defines three sets of reserved words. The first set is "keywords", which are all used by the current version of the language. Here's the full list (ES5 §7.6.1.1):
break | case | catch | continue | debugger | default | delete |
do | else | finally | for | function | if | in |
instanceof | new | return | switch | this | throw | try |
typeof | var | void | while | with |
The second set is "future reserved words", which are not currently used by the language but are expected to be used in the future. They are reserved now so that future code is backwards compatible. Here's the full list (ES5 §7.6.1.2):
class | const | enum | export | extends | import | super |
The third set is made up of identifiers that are also considered future reserved words, when they occur within strict mode code. JSLint will treat them in the same way as all of the previously listed reserved words, regardless of whether the code is in strict mode or not. Here's the list:
implements | interface | let | package | private | protected | public |
static | yield |
For the second example above, this error is raised to highlight a potential JavaScript syntax error. Your code will not run in browsers that do not support this feature of ECMAScript 5 (notably Internet Explorer 8 and below). If you do not care about these older browsers, you can tell JSLint to ignore this syntax by using the es5 directive:
However, if you do need your code to run in older browsers, you will need to change your syntax slightly and quote the identifier so it's treated as a string rather than a reserved word:
Updated 5th December 2012. As of today, this bug has been fixed in JSHint. The online tool has not yet been updated, so that still contains the bug. Currently, the bug remains in JSLint. Further updates will be added if/when the issue is fixed in JSLint.
Updated 14th December 2012. This bug has now been fixed in JSLint.
If you set the es5 JSLint or JSHint option to true there is a chance you will come across a bug in the JSLint parser. The problem is that JSLint will not warn you about invalid JavaScript that will in fact cause a syntax error. If you rely on JSLint to give confidence in your code when deploying to your production environment, this could potentially be a major issue.
The bug remains in JSHint (which started life as a straight fork of JSLint), but I have raised an issue on GitHub and prepared a pull request to fix the bug. This article will be updated if and when the bug is fixed in both JSLint and JSHint.
Consider the second example on this page, which JSLint correctly flags as containing an error. By setting the es5 option to true, you can prevent warnings for this kind of syntax, as shown in the third example on this page. However, in this situation, older versions of both JSLint and JSHint will not give you a warning for code like this:
The above example will generate a syntax error in all JavaScript environments, regardless of ECMAScript 5 support. You cannot use a reserved word as a variable or function identifier.
In JSHint 1.0.0 and above you have the ability to ignore any warning with a special option syntax. The identifier of this warning is W024. This means you can tell JSHint to not issue this warning with the /*jshint -W024 */
directive.