Decide which versions of Node we officially support

[domoscargin]

What

We should decide which versions of Node we test on and officially support, and we should implement this decision.

Why

We currently test Node version 12, 14, 16 and 18. v12 is no longer supported, v14 will reach end of life in April, v16 entered maintenance in October, and v18 is the current release.

Who needs to work on this

Developer, Content Designer

Who needs to review this

Developer, Product Manager?

Done when

• We have decided which versions of Node we will support
• We have made sure our tests pass using our new Node support matrix
• We have documented this change for our users
• We have merged the changes

[domoscargin]

When we eventually consider dropping Node 12 support, we must remember to look at our lockfile version: #1151

[lfdebrux]

I'd like to do this as part of the release for v13 of the kit, as this is a breaking change, but something we should do soon. In my opinion we should definitely drop support for Node 12, and also consider dropping support for Node 14. Node 14 is currently in maintenance mode, reaching end-of-life in April next year [1], while Node 12 reached end-of-life in April this year [2]. These two versions also are distributed with npm 6, which is also a legacy version [3] and has a number of bugs and missing features.

[ruthhammond]

Team discussion initially - Ruth to set up an initial 30 minute session next sprint
To discuss (not exhaustive):

• Does supporting 12 cause us problems?
• What are the criteria for answering this in the future?

Info needed for session:

• Joe to look at the data to review in the session
• Ask our users on Slack (Joe and Amelia to work on the question(s) to pose together)

[lfdebrux]

One thing we should also consider for this ticket is how we want to update the engines field in our package.json file.

One thing I think we should consider is removing the upper limit. I did a search, and no package we depend on has an upper limit on the version of Node it supports in the engines directive. I also had a look at some other popular packages we don’t depend on, and none of those had an upper limit. I think it is not common practice.

We could also consider making it clearer we only support LTS releases, similar to how other packages do, by only including even numbers in the version range. @colinrotherham made a suggestion similar to this in #1700 (comment).

[joelanman]

I did some analysis of Node versions in our usage data (internal)

[lfdebrux]

Arguments for not supporting v14 from @nataliecarey:

I think we can make a good argument for supporting 16 & 18 only.
It's in maintenance, support is being dropped in 5 months (within the predicted lifespan of v13) and if we find we made the wrong decision it will be a non-breaking change to include v14 support.

[ruthhammond]

As this decision is blocking v13 work, I'm happy to make the call that we support 16 and 18 only.
This would be on the same basis as currently - i.e. we don't block older versions, so users can continue to use them at their own risk.

In terms of a policy for how we support versions going forward, I propose that once a version is in maintenance and within 6 months or less from end of life, we stop providing support for it.

[lfdebrux]

v13 now supports Node 16 and 18 only (see #1753). I'll also update the README to include a note about how we decide what versions of Node to support going forward.