Warn if package-lock has newer version than package (even if semver-compliant)

[jakub-g]

What / Why

Hi, I'm not sure this is change is welcome, but I wanted something like this for my own purposes anyway, so I thought I'll open the PR and see.

While the promise of package-lock is that no longer different developers have different versions of the same package and this promise is fulfilled, it doesn't guarantee that version defined in package.json is actually the one that all the developers have if package.json field uses ^ or ~ ranges, (which is default behavior when someone does npm install _some_package_)

This is of course a known feature of npm and the whole point of having ranges. But it's still confusing. In fact, most of the time (by default) the two versions are aligned, until someone nukes package-lock (for example due to merge conflict) and does npm install which regenerates it from scratch_.

This PR displays warnings like this in such a scenario:

Warning: package-lock is newer than package: 6.24.1 ^6.23.0 babel-plugin-transform-react-jsx
Warning: package-lock is newer than package: 4.2.8 ^4.2.3 node-bourbon
Warning: package-lock is newer than package: 6.10.3 ^6.9.0 eslint-plugin-react
Warning: package-lock is newer than package: 14.6.0 ^14.5.8 graphql

(I had to update semver to have semver.minVersion).

Looking forward to comments.

[jakub-g]

This is related to raineorshine/npm-check-updates#628

Since ncu does not check package-lock, it finds some no-op updates like the ones above that are effectively no-ops (they only update package.json but nothing new will be installed actually after npm install, because the new version is already there, and package-lock.json won't be updated because it's already up to date, which is quite confusing).

[jakub-g]

At the end of the day, I know that perhaps if one wants to avoid the discrepancy due to semver, the solution is "just use fixed versions, and use npm install --save-exact", however this warning is useful for cases when the discrepancy is already there. (Maybe it should be behind a command line flag?)