Best practice 'package-lock.json' for modules

[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