Align to Node.js supported versions
joeyguerra opened this issue · comments
Proposal
Let's align to Node's End of life schedule for version support.
@levenleven. I created an issue to discuss and plan a release.
Makes sense to me! It helps to know what we're agreeing on as "supported", since support may be interpreted differently. For me this means something like:
- "The supported range" is defined as whatever Node.js says is currently in their support range (current, active, maintenance versions; as of today v14, v16, v18, v20).
- We update the package.json
engines
in hubotio/hubotpackage.json
from> 4.0.0
to indicate the lower bounds of the supported range (currently>= 14
). - Maybe introduce a "Requirements" section to install/setup docs?
- Tests are configured in this project to run on the supported range. We aim to ensure test coverage stays green.
- Folks reporting issues against older Hubot versions are asked to try reproducing with a current Hubot release
- Folks reporting issues when using Node.js versions outside the supported range are asked to try reproducing with a supported Node.js version
To me it doesn't mean that we introduce code to prevent Hubot running on unsupported Node.js versions (warning messages are fine, and the engines
entry will trigger a warning at runtime if Node.js is not aligned to the Hubot release).
I suspect adding an upper bound on the engines entry will only create work; new versions will come out and folks will say "Hubot doesn't install", because the chore of bumping the max engine value hasn't yet been done? So I propose "engines": {"node": "> 14"}
.
Likewise, in 7d91cee we introduced a test matrix of [ 14.x, 16.x, 18.x, latest ]
, currently against Linux, Windows and macOS runners. I used latest
there so that when a new release appears in Github's list of Node versions, our coverage lifts automatically.
When Node.js v14 hits EOL (less than a week away), there's a chore to bump the version, but it's not urgent. Our motive for defining a supported range is to provide clarity of what we think works, not to police how it's consumed. Lots of folks run old versions of things ... what we do is disable test coverage for that version and bump the supported versions. Existing bots should continue to run, and will start to warn about Node.js if/when the hubot
dependency is updated in that bot install.
I agree with all of the above except I'd like some clarity on:
To me it doesn't mean that we introduce code to prevent Hubot running on unsupported Node.js versions (warning messages are fine, and the engines entry will trigger a warning at runtime if Node.js is not aligned to the Hubot release).
Is another way to say this is that we don't add code that checks what Node.js version is running AND throw an exception if it's not within the supported range?
I think I would generally avoid checking against a version at all unless there's no way to detect feature support 👃🏼
And I think a "bail out if running on unsupported version" code path is redundant. Leave it to throw an exception when something illicit happens.
(Maybe if there were a ton of people filing bug reports against outlandish old node versions and there was a need to send a signal ... maybe.)
I think mentioning the minimal supported node version in readme (or just linking the End of life) and corresponding test runner matrix coverage is good enough. We could probably skip the engines
setting, if folks are using it with older node version - shouldn't bother us
Ok. This all sounds good to me too. I was hoping to get the other chore
PRs merged and released before implementing this plan.