Best practice 'package-lock.json' for modules

sdetweil

@mumblebaj right it’s good for teams and automated test. but not here.

os at different levels, architectures, node levels.

I test on Jetson nano, odroid the entire pi family, amd64, arm64, lots of different Linux OS es, virtual machines on amd and arm

package-lock is useless and an inhibitor.

modules should NEVER ship it.

KristjanESPERANTO

Wouldn’t that also be a good idea for the core? It would probably make sense to use the same strategy for the core as for the modules.

@rejas @karsten13

sdetweil

@KristjanESPERANTO well we use it to control the test platforms. but you can’t delete it for clone

sdetweil

@KristjanESPERANTO i just did an npm ci in a module folder with no package-lock.json and it complained that it required package-lock.json

pi@raspberrypi5:~/Documents/MagicMirror/modules/MMM-Soliscloud $ npm ci
npm ERR! code EUSAGE
npm ERR! 
npm ERR! The `npm ci` command can only install with an existing package-lock.json or
npm ERR! npm-shrinkwrap.json with lockfileVersion >= 1. Run an install with npm@5 or
npm ERR! later to generate a package-lock.json file, then try again.
npm ERR!

KristjanESPERANTO

That’s the point of npm ci it takes the package-lock.json to install and it don’t change it.

KristjanESPERANTO

well we use it to control the test platforms.

Can you show me where?

sdetweil

@KristjanESPERANTO in the npm install on the different test instances. I don’t build those

these are effectively docker images, build and execute, throw away

karsten13

@KristjanESPERANTO said in Best practice 'package-lock.json' for modules:

Can you show me where?

we don’t use npm ci but I’m not sure what npm install does if package-lock.json is present.

I do the tests after building my docker images on my own and I always delete package-lock.json before running npm install to be sure getting the newest deps.

sdetweil

@karsten13 package-lock is SUPPOSED to insure installing EXACTLY those versions every time