The Lambda Layer builds and coming #2622 means we should start using a package-lock for repeatable builds.

Also, turning on using dependabot for the repo (and should do so for the http-client repo as well) will probably help us keep package-lock.json updated.

Also, can we start using npm ci instead of npm install in our CI builds to speed them up? I'm not sure if npm ci was there for the npm version in node v8.6 (our current base node version).

IIUC, a slight downside of using package-lock.json is that our regular testing will not test with the same (latest published versions of) deps that a user would get when using "elastic-apm-node": "..." in their project deps. But, then again, that not running with the current latest is the point. :)

checklist

• Add a package-lock.json file.

• See if we can use --ignore-scripts for the Lambda Layer build.

• Decide on, and if "yes", setup dependabot to help with maintaining package-lock.json -> enable dependabot for this repo #2689

• Create a follow-up ticket, once we have a package-lock file, to work through https://github.com/elastic/apm-agent-nodejs/security/dependabot items.

• See if we can use npm ci in some places for CI tests. npm ci isn't supported in the npm v5 that is part of our Node 8.6 runs. However, we could consider npm install -g npm for node v8 runs, or just fallback to npm install given this is about speeding up the install step. Does TAV use npm ci if possible?
  Moved this to s/npm install/npm ci/ in tests and builds #2682 to do after we drop node v8 support.

• Use a supported version of npm for building release packages so we can be sure we get security fixes. Note that what npm versions get security fixes is not exactly clear: Current npm docs just say "use the latest version", which I suppose is an option, but I've generally be hesitant or didn't feel the need to use a version of npm other than the one that came as part of that node version install. An old npm blog on LTS policy said:

  In the event of a security issue, the npm CLI project will back port security patches to any version of npm currently shipping with a supported Node.js version, that is to say, any Node.js version still in its maintenance window.

  We are using node v16.15.0 (the current latest node v16 at the time), mainly to get the npm v8 that comes with node v16 (and not with node v14) that uses lockfileVersion: "2". Node v16 is the current "active" node branch. Any node v14 users that work on the repo directly will have the inconvenience of the package-lock.json file getting downgraded to lockfileVersion:1. We'll have to be on the lookout for PRs that accidentally do this, but I don't anticipate it being a big issue.