The switch is mostly mechanical, with assertions translated 1:1. The
biggest non-mechanical part is rewriting Jasmine custom matchers as Chai
helpers. The matchers were streamlined and simplified in the process and
their messages were made more in line with messages produced by built-in
Chai helpers.
Fixes#409.
This fixes the following ESLint error, which started to appear after
eslint/eslint#7424 was fixed:
/Users/dmajda/Programming/PEG.js/pegjs/lib/compiler/js.js
37:17 error Unnecessary escape character: \] no-useless-escape
This should fix broken Travis CI builds:
https://travis-ci.org/pegjs/pegjs/builds/180092802
Instead of specifying tasks that are part of the "default" task using
dependencies and running them in parallel, execute them serially using
"run-sequence". This makes things deterministic and ensures that all
messages from all tasks are seen in the output (which wasn't the case
before, leading to confusion).
Version information is already present in package.json and no code uses
the VERSION file anymore. It doesn't make sense too keep it just for the
sake of following an old convention as it is a maintenance burden.
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.
Generating AMD/UMD dependencies lead to an error:
$ bin/pegjs --format amd --dependency $:jquery examples/arithmetics.pegjs
dependencyIds is not defined
$ bin/pegjs --format umd --dependency $:jquery examples/arithmetics.pegjs
dependencyIds is not defined
This commit fixes the problem, which was caused by a mistake done in
d2569b9bf3.
The "global-require" rule is disabled in ESLint configuration used by
PEG.js, but the idea is not bad, so let's make all static "require"
calls global.
Follow-up to #407.
Running ESLint on generated code with the configuration used on PEG.js
itself produces a lot of errors. This commit fixes some unnecessary ones
caught by these rules:
- max-len
- new-cap
- newline-before-return
- no-unused-vars
See also 5dd8e797f7.
Follow-up to #407.
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 LICENSE file used weird word wrapping and it didn't explicitly name
the license. I'm not sure where I originally copied it from.
I decided to replace it with more standard form from here:
http://choosealicense.com/licenses/mit/
The content of the license stays exactly the same.
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).
This makes extractList identical to the same function in other grammars
and makes it so that nulls are dealt with in only one function (until
now, they were dealt with both in extractList and buildList).
The refactoring should be safe as extractList isn't by itself used in
contexts where it can be passed a list containing nulls.
Blocks of one-line rules with aligned "=" signs should be used only in
cases where the rules are symmetric and we want to emphasize that.
Follow-up to ff7193776e.
David Majda