Specify Node version 16

[victorlin]

Description of proposed changes

It's recommended to set the Node version explicitly¹, otherwise the build server chooses a default which can change unexpectedly. For example, this change was prompted because Heroku recently switched from 16 to 18. Auspice doesn't work on 18 yet², so we need to use 16.

¹ https://devcenter.heroku.com/articles/nodejs-support#specifying-a-node-js-version
² nextstrain/auspice#1553

Related issue(s)

N/A

Testing

• Manually inspect Heroku build log (ref)
• Preview app opens

[victorlin]

Build output:

-----> Building on the Heroku-22 stack
-----> Using buildpack: heroku/nodejs
-----> Node.js app detected

...

-----> Installing binaries
       engines.node (package.json):  16.x
       engines.npm (package.json):   unspecified (use default)
       
       Resolving node version 16.x...
       Downloading and installing node 16.18.0...
       Using default npm version: 8.19.2

This looks good, but I noticed that if the npm version is not specified, it defaults to the latest version compatible with the node version. The only potential issue I can think of is having different package-lock.json files due to developers having npm <=6 (lockfile v1) vs. >=7 (lockfile v2). I don't think this can be enforced through the engines alone. Even when specifying "npm": ">=7", a local environment with Node.js v14.18.3 and npm 6.14.15 does not produce any warnings when running npm ci. On the other hand, a local environment with Node.js 18 shows a warning as expected:

npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '[email protected]',
npm WARN EBADENGINE   required: { node: '16.x' },
npm WARN EBADENGINE   current: { node: 'v18.10.0', npm: '8.19.2' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '[email protected]',
npm WARN EBADENGINE   required: { node: '^12 || ^14 || ^16', npm: '>=6.9' },
npm WARN EBADENGINE   current: { node: 'v18.10.0', npm: '8.19.2' }
npm WARN EBADENGINE }

So I think it's fine to leave this change as-is (node version enforcement), and npm version enforcement can come later.