DX decisions

[saragerion]

package-lock.json vs npm npm-shrinkwrap
Node version?
NPM version?

[dreamorosi]

As agreed offline I have been researching these topics, hopefully it can help us make a decision.

1. package-lock.json vs npm-shrinkwrap.json

Context

To begin, both files can coexist in the same project root but if both package-lock.json and npm-shrinkwrap.json are present in the root of a project, npm-shrinkwrap.json will take precedence and package-lock.json will be ignored [1].

Both files allow to describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies [2]. The two files are identical, with one major caveat: Unlike package-lock.json, npm-shrinkwrap.json may be included when publishing a package [3], while package-lock.json cannot be published, and it will be ignored if found in any place other than the root project [4]. Quoting the npm docs [5]:

The recommended use-case for npm-shrinkwrap.json is applications deployed through the publishing process on the registry: for example, daemons and command-line tools intended as global installs or devDependencies. It's strongly discouraged for library authors to publish this file, since that would prevent end users from having control over transitive dependency updates.

In regards to dependabot according to the docs and this PR both formats are supported.

Proposal

My proposal is to drop npm-shrinkwrap.json (where used) in favor of package-lock.json. Our intended usage aligns more closely with the latter since it'll allow to have a consistent environment during development and CI/CD but at the same time allow Customers to retain control over their dependency tree.

2. Node version

Context

Currently AWS Lambda officially supports nodejs10.x, nodejs12.x, nodejs14.x runtimes:

• nodejs10.x runtime is currently in the second phase of the deprecation cycle [6], which means Customers are not able to create or update functions that use this runtime. From the Node.js side, the runtime has reached EOL and has stopped receiving security support on 30 Apr 2021 [7].
• nodejs12.x runtime is actively supported by AWS Lambda while according to the Node.js release schedule it is currently in maintenance mode and will continue receiving security support until 30 Apr 2022 [8] when it will reach EOL.
• nodejs14.x runtime is also actively supported by AWS Lambda and has entered maintenance mode on Node.js' end on 19 Oct 2021. The runtime will continue receiving security support throughout 30 Apr 2023 [9].

Proposal

Since a runtime for the current active release (nodejs16.x) is not available on AWS Lambda, I propose prioritising nodejs14.x as primary runtime and Node version, with optional automated testing on nodejs12.x. On the other hand, given that this project has not been published yet and Customers won't be able to use it in any nodejs10.x function (since updating dependencies would force them to move to another runtime) we should drop support and testing for that runtime.

3. NPM version

Context

The official NPM documentation [10] currently features only the latest three major version of the tool: v6.x, v7.x, v8.x with the first two indicated as "Legacy release" and the latter as "Current release". According to the releases page [11] for Node.js:

• >=v6.9.0 was bundled with Node.js from version 12.0.0 to 14.18.2 (last 14.x release of Node.js).
• >=v7.x was bundled with Node.js from version 15.0.0 to 16.10.0 (last 16.x release of Node.js),
• >=v8.x is being bundled with Node.js since version 16.11.0 (current last is 17.3.0).

v7.x was announced as GA on 2 Feb 2021 [12] while v8.x was released on 7 Oct 2021 [13]. Both versions feature breaking changes with the most notables in terms of Node.js support being that v8.x of npm drops support for nodejs10.x [14].

Note: The section above doesn't take Node.js v10.x into consideration due to its EOL status.

Proposal

My proposal is to use either v7.x or v8.x of npm although I don't have a strong recommendation on this topic and would be happy to hear opinions of those who have stronger arguments.

[dreamorosi]

PR #492 set the Node.js version to lts/fermium - 14.x (current Active LTS) & npm 8.x.

[flochaz]

1. +1 on package-lock.json
2. I would force us to test Node 12 to start having tests matrix which will make easy future extension of tested runtimes
3. From https://www.npmjs.com/package/npm it looks like v8 represent 44% of the download , 32% for v7 and 22% for v6 , so I would go for v8

[michaelbrewer]

.nvmrc could be a good way to ensure developers have the right version installed. I have a PR for codespaces and gitpod that tries to make things easier:

• https://github.com/awslabs/aws-lambda-powertools-typescript/pull/485/files

[michaelbrewer]

I would consider using yarn over npm. But otherwise nodejs14.x makes sense, as nodejs12.x support will be dropped soon and nodejs10.x will be deprecated by AWS Lambda too?

[dreamorosi]

Yes, strong agree on the .nvmrc suggestion. Do you know if there's a way to similarly enforce the npm version in a project aside from relying on the dev reading the documentation / contributing docs?

[michaelbrewer]

Possibly via a makefile that does setup and requirement checks?

[michaelbrewer]

Looks like you can set "engines" versions for node and npm. But for some reason this has been deprecated.

https://javascript.plainenglish.io/why-and-how-to-use-stable-node-and-npm-versions-across-your-project-team-a4886f51a96c

[michaelbrewer]

By the time this is in GA it would be safe assume that Node V14 should be the minimum supported version and based on the ts transpiler producing es2020, the safest option to use.