Add npm `package-lock.json` for npm v5.x

[netweb]

npm v5 now by default generates a package-lock.json file

Some paraphrased notes from the announcement post: ​http://blog.npmjs.org/post/161081169345/v500

• package-lock.json and npm-shrinkwrap.json are aware of each other and happy to coexist

• package locks no longer exclude optionalDependencies that failed to build. This means package-lock.json and npm-shrinkwrap.json should now be cross-platform.
  • This will hopefully mitigate the optionalDependencies issue with our build server in #38657 / r39368, when the build server is bumped to use the upcoming Node.js v8.x LTS release this can be tested and confirmed.

• Running npm while offline will no longer insist on retrying network requests. npm will now immediately fall back to cache if possible, or fail, npm's caching is vastly improved in npm 5

• On performance, NodeJS 6.9.1 and NPM 3.10.8 running npm install in tests took ~67.39 seconds on average, with NodeJS v7.10.0 and npm v5.0.0 this is halved to ~28.938 seconds on average, once npm modules are cached reinstalling node_modules averages 23.091 seconds, just shy of a 3x speed boost
  • Detailed bbPress, BuddyPress, and WordPress performance tests can be seen in ​this spreedsheet
  • The performance boost is comparable to that of Yarn, initial install 21.40 seconds, and subsequent installs 18.82 seconds, see #38603

Related: #38603 Explore adding Yarn and a yarn.lock file for NPM module management

[netweb]

Via ​https://docs.npmjs.com/files/package-lock.json

One key detail about package-lock.json is that it cannot be published, and it will be ignored if found in any place other than the toplevel package. It shares a format with npm-shrinkwrap.json, which is essentially the same file, but allows publication.

This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages.

If both package-lock.json and npm-shrinkwrap.json are present in the root of a package, package-lock.json will be completely ignored.

With a switch to npm 5 as the minimum required version this would also eliminate the need to commit a npm-shrinkwrap.json file to each branch at release time, refer to #40928 / [40878] for 4.8 for example

That said bumping npm version requirements is for another ticket, possibly #35105 if it remains open long enough

[netweb]

Punting for now, there's an intermittent issue with npm 5 and Travis CI cache, will re-milestone once thats resolved

​https://github.com/npm/npm/issues/17419

[netweb]

Once a few dependencies have been updated following WordPress' "build" server and this repo bumping Node.js to 8.9.3 for WordPress 5.0 let's commit both a yarn.lock and package-lock.json to the repo, users can choose their tool of choice.

Using the ​synp package should allow us to keep both lock files in sync programmatically.

[azaozz]

Perhaps for now we should add package-lock.json and even yarn.lock to svn ignore and gitignore. There is no point in producing "messy" diffs with warnings about unversioned files, and tripping up people that want to make a patch. They can be "unignored" easily when the time comes.

I'm also not so keen on using (yet another) package to keep these lock files synced. See the caveats section in the synp docs: ​https://www.npmjs.com/package/synp#caveats. Ideally we should stick to either package-lock.json or yarn.lock and ignore the other.

[netweb]

A package-lock.json file was committed in [43309] as part of #43055

[jorbin]

committed to 5.0 in [43684]