The idea behind linting lib/parser.js was that it would improve quality
of code generated by PEG.js in general. However, there is a couple of
problems with it:
1. Code in lib/parser.js is ES5 while the rest of the code is ES2015.
This would mean a separate ESLint configuration and a separate set
of code style rules just for lib/parser.js once code style checks
are added.
2. Code in lib/parser.js is generated. This means that even today it
violates checks like "no-unused-var", which have to be disabled.
This would get worse once code style checks are added, again
requiring a separate ESLint configuration just for lib/parser.js.
3. Linting lib/parser.js checks only small portion of possible code
generator output. For example, code generated when optimizing for
size or when tracing is not checked at all. Thus, linting
lib/parser.js gives a false sense of security.
Because of these problems I decided not to lint lib/parser.js at all and
rely on ad-hoc linting of parser files produced by PEG.js with ignoring
false-positives. I consider this more of a pragmatic cost vs. benefits
decision than a principial one.
Part of #407.
Before this commit, continuation lines of multi-line values in variable
declaration initializers were aligned with the variable name:
let foo = {
a: 5,
b: 6
};
This was highly irregular, maintenance intensive, and made declarations
look different from assignments.
This commit changes the indentation to be more regular and similar to
assignments:
let foo = {
a: 5,
b: 6
};
The lib/parser.js file is a CommonJS module like all the other files in
lib/, so setting the environment explicitly is not needed. Besides, the
environment set by "eslint-env" was wrong (since transitioning from the
AMD format).
Use one var/let/const per variable, but only for initialized variables.
Uninitialized variables are still grouped into one var/let/const
declaration as I don't see any value in separating them. This approach
reflects the fact that initialized and uninitialized var/let/const
declarations are really two different things.
See #443.
The for-in statement in JavaScript iterates also over inherited
properties. This is typically not desired and requires adding a
check using Object.prototype.hasOwnProperty inside the loop.
This commit replaces all for-in statements and related checks inside
them with iteration over Object.keys(...). The iteration is performed
using either Array.prototype.forEach of a plain for loop.
Because arrow functions work rather differently than normal functions (a
bad design mistake if you ask me), I decided to be conservative with the
conversion.
I converted:
* event handlers
* callbacks
* arguments to Array.prototype.map & co.
* small standalone lambda functions
I didn't convert:
* functions assigned to object literal properties (the new shorthand
syntax would be better here)
* functions passed to "describe", "it", etc. in specs (because Jasmine
relies on dynamic "this")
See #442.
This is purely a mechanical change, not taking advantage of block scope
of "let" and "const". Minimizing variable scope will come in the next
commit.
In general, "var" is converted into "let" and "const" is used only for
immutable variables of permanent character (generally spelled in
ALL_CAPS). Using it for any immutable variable regardless on its
permanence would feel confusing.
Any code which is not transpiled and needs to run in ES6 environment
(examples, code in grammars embedded in specs, ...) is kept unchanged.
This is also true for code generated by PEG.js.
See #442.
Parsers generated in this format use module.exports, so they are not
strictly CommonJS, but this is a common extension and the original name
would be confusing once Node.js implements ES2015 modules.
David Majda