treat package-lock.json the same way we treat package.json if checksum changes

[nolessafool]

currently we re-run npm install in case the checksum of package.json changes:

https://github.com/netlify/build-image/blob/master/run-build-functions.sh#L114

We should do the same if package-lock.json exists and is changed, and someone who knows what they heck they're doing should decide if the presence of package-lock.json means that we don't even worry about changes to package.json at that point while this code gets written

[frangio]

I just ran into this issue.

Comparing the checksum of package-lock.json is not enough. There are many possible scenarios. Some repositories may not have a package-lock.json and only a package.json. Others may have an npm-shrinkwrap.json in its place. Technically all those three files should be compared.

[frangio]

Oh, okay, that's exactly what was done in #114. I'm not sure why it was reverted afterwards.

[ianschmitz]

Any word on this? Lock files should definitely be included in the cache check.

[denis-sokolov]

This issue breaks security updates. “npm audit fix“ updates sub-dependencies. It does so by changing the lock file, not the package.json file. Netlify builds and deploys a new version of the website, but it silently uses old, cached versions.

This breaks the workflow with npm 7 workspaces. The top-level package.json seen almost no changes in that version. Dependencies are described in nested package.json files, and installation details are all in the lock file. Any time we change a dependency, we need to manually clean Netlify cache.

/moduleA
  /package.json
/moduleB
  /package.json
/package.json
/package-lock.json

Please reconsider adding #114 back.

[kitop]

A change for this has been rolled out, we now always run npm install even when a package-lock.json exists.