Best practice 'package-lock.json' for modules

[KristjanESPERANTO]

Why npm ci doesn’t help? It doesn’t change the package-lock.json.

[sdetweil]

@KristjanESPERANTO but something else will over the months. and we have to retrain all our users.

[KristjanESPERANTO]

but something else will over the months.

“something else” will change the package-lock.json? How can that happen?

and we have to retrain all our users.

This is certainly a considerable disadvantage compared to approach 1.

[sdetweil]

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

“something else” will change the package-lock.json? How can that happen?

someone will forget to be in the modules folder and poof it happens at the root…

[Jalibu]

It is generally recommended best practice to check-in the package-lock.json for node modules.
However, I in our case of MM-Modules the disadvantages clearly outweigh the expected advantages in my opinion.

In my modules, it is therefore part of .gitignore

[KristjanESPERANTO]

@Jalibu I just wanted to point you to this conversation. Thanks for your feedback! :-)

I’m thinking about adding a check for it to my project.

[mumblebaj]

My 2 cents worth.

@Jalibu I agree with your view.

It is highly recommended you commit the generated package lock to source control: this will allow anyone else on your team, your deployments, your CI/continuous integration, and anyone else who runs npm install in your package source to get the exact same dependency tree that you were developing on.

See npm documentation

@KristjanESPERANTO Personally I always add it to .gitignore along with node_modules folder.

[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