Espree #85
Espree #85
Conversation
brettz9
force-pushed
the
espree
branch
2 times, most recently
from
884e7cd
to
7f6743c
Compare
brettz9
force-pushed
the
espree
branch
2 times, most recently
from
a9d2d73
to
8a374b9
Compare
- Fix: Multiple leading decimals were not being handled correctly (produced inner
array followed by "." such that `21.` (e.g., at beginning of "21.35") would be
procssed instead as `2,1.`)
- Enhancement: Throw for unknown operator
- Refactoring: Avoid unnecessary code to unescape `\\a` (`\a` has no special meaning)
- Maintenance: Add pegjs as 2 sp. in `.editorconfig`
- Testing: Expand to effective 100% coverage
- Testing: Switch from jstestr to mocha
- Testing: Get coverage for bad operator, class name, and selector type
|
I don't know if we should switch to espree without reason. Is there something espree supports that esprima doesn't that we want? |
|
The reason is just that it appears to be more actively maintained (see https://github.com/eslint/espree/#why-another-parser ). There are a list of a few differences at https://github.com/eslint/espree/#known-incompatibilities . My thinking was not about a perceived defect but merely that while espree aimed at compatibility, it might be better to ensure the project is working against the expectations of a more actively maintained project, and one which is used by the large eslint community. But this is not a big issue for me if you don't think it is warranted. |
Co-Authored-By: Michael Ficarra <github@michael.ficarra.me>
…age.json#preferglobal - Fix test name to reflect contents
|
Let's hold off on this one for now, at least until we have an actual observable benefit. |
Builds on #81, #82, #83, #84.
preferGlobal: https://docs.npmjs.com/files/package.json#preferglobal