Best practice 'package-lock.json' for modules

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!