The core of the transition is getting rid of Makefile and replacing it
with gulpfile.js. The rest is details (fixing dependencies, changing all
references to "make", etc.).
Target/task names mostly stay the same, so in most cases "gulp foo" does
what "make foo" did before. The only exceptions are "make browser" and
"make browserclean", which are now "gulp browser:build" and "gulp
browser:clean" (it feels more systematic).
Functionality is mostly unchanged (modulo Gulp clutter in the console),
but there are two small exceptions:
gulp spec
The reporter now displays just dots while previously it displayed
spec descriptions. There is also a deprecation warning (most likely
because I used an old version of gulp-jasmine in order to support
Jasmine 1.x). I kept these issues unfixed because I plan to switch
to Mocha soon (#409).
gulp browser:build
The copyright header is now added manually both to the development
and minified build. Before, it was added only to the development
build and the minified build relied on preserving it using "uglify
--comments". This was broken since switching to //-style comments.
There is now also an empty line between the header and the source
code.
Fixes#444.
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
};
Move "use strict" directives to the first line of each file. In
particular, move them above any ESLint comments, which are far less
important.
There are few exceptions:
Executable files
In these, the "use strict" directive must give way to the shebang.
lib/parser.js
Here, the "Generated by..." comment comes first. Also, ESLint
comments are prepended in post-processing.
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.
This will allow to use ES2015 constructs in spec code.
The change required introducing a small server, which serves both PEG.js
and spec code passed through Babel and bundled together. This allowed to
convert the specs to regular modules and get rid of the hackery that was
previously needed to make them run both in Node.js and in the browser.
Note the specs no longer exercise the browser version. This will allow
to spec PEG.js internals in the future.
See #442.
Rename compiler passes as follows:
reportLeftRecursion -> reportInfiniteRecursion
reportInfiniteLoops -> reportInfiniteRepetition
This reflects the fact that both passes detect different ways of causing
the same problem (possible infinite loop when parsing).
The new terminology is more precise and in line with commonly used
programming languages.
The change involves mainly renaming related compiler pass and files
associated with it.
The "parser" variable allowed access to the parser object. Among other
things, this made it possible to invoke the parser recursively using
"parser.parse".
One problem with the "parser" variable is that it bakes in the idea that
the parser is an *object*, not a *module*. While this is true now, it
won't necessarily be in the future, when parsers may be exported as ES6
modules. Also, people tend to use parsers as modules even today, e.g.
like this:
var parse = require("parser").parse;
var result = parse(...);
Such usage broke the "parser" variable (as it was implemented).
For this reasons I decided to remove the "parser" variable. If someone
needs to do tricks like recursive invocation of the parser, he/she must
pass the parser or the "parse" function itself using options.
Related to #433.
David Majda
Mingun