describe supported versions of Node in engines field in package.json

[HonkingGoose]

You can use the engines field in your package.json to describe what versions of Node you support.
This will warn users when they are trying to use a version of Node you don't support.

Example:

"engines": {
  "node": "^6 || ^8 || ^10 || ^12 || ^14"
}

This would denote that you support Node 6, 8, 10, 12 and 14.
If a user tries to use Node 15, they would get a warning.

Unless the user has set the engine-strict config flag, this field is advisory only and will only produce warnings when your package is installed as a dependency.

You can read the official npm docs for the engines field here: https://docs.npmjs.com/cli/v6/configuring-npm/package-json#engines

Read more about the versioning scheme here: https://docs.npmjs.com/cli/v6/configuring-npm/package-json#dependencies

Let me know if you want a PR from me to add this.

[Jimbly]

Nah, this module should usually run on any node version, usually just the tests on unstable Node versions often fail (because they're a copy of the tests from Node testing Node's HTTP layer, using this low level parser - unless they get updated when Node changes it's internal behavior, they often star failing, despite nothing actually being broken in this module). It's just the most thorough way to test this module (but necessarily has tests tightly coupled with Node versions). Also, though most people use this module by monkey-patching it in as a replacement under Node's HTTP layer, at least one project is (was?) using it as just an parser for their own HTTP layer (and that's totally uncoupled from Node versions, so will work on any old or new version), so it would be a little annoying to warn for people using it in that way, but maybe it'd be okay.

[HonkingGoose]

Thanks for considering this issue, and for giving me a response. 😄