Align with Node's support policy by targeting oldest LTS.
Use promise-based APIs out-of-the box (without having to use bluebird)
Remove workarounds for old Node versions
Refactor the internals to use ES syntax (scoped variables, spread args, arrow functions, etc.)
Supporting unmaintained Node versions is proving to be an increasing burden as third party libraries drop support for it (cross-spawn, tap). Using ES5 syntax while ES2015 brought a lot of improvements to the language is also a weight on maintenance. Finally, this is a pretty mild breaking change: there is no intent to break API compat. Since it implies a semver major update, it will be opt-in and only affect users explicitly updating their projects. The primary motivations for this PR is improving coverage tools using V8, a feature only present on modern Node versions anyway.
What
Update CI to run against the currently supported Node versions: Node 6, 8 and 10.
Add engines.node field to package.json to warn users trying to use the library on an unmaintained Node version.
Why
Supporting unmaintained Node versions is proving to be an increasing burden as third party libraries drop support for it (
cross-spawn
,tap
). Using ES5 syntax while ES2015 brought a lot of improvements to the language is also a weight on maintenance. Finally, this is a pretty mild breaking change: there is no intent to break API compat. Since it implies a semver major update, it will be opt-in and only affect users explicitly updating their projects. The primary motivations for this PR is improving coverage tools using V8, a feature only present on modern Node versions anyway.What
engines.node
field topackage.json
to warn users trying to use the library on an unmaintained Node version.