Read the statement by Michael Teeuw here.
Best practice 'package-lock.json' for modules
-
@KristjanESPERANTO but something else will over the months. and we have to retrain all our users.
-
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.
-
@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…
-
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
-
@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.
-
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.
@KristjanESPERANTO Personally I always add it to
.gitignorealong withnode_modulesfolder. -
@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.
-
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.
-
@KristjanESPERANTO well we use it to control the test platforms. but you can’t delete it for clone
-
@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! -
That’s the point of
npm ciit takes thepackage-lock.jsonto install and it don’t change it. -
well we use it to control the test platforms.
Can you show me where?
-
@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
-
@KristjanESPERANTO said in Best practice 'package-lock.json' for modules:
Can you show me where?
we don’t use
npm cibut I’m not sure whatnpm installdoes ifpackage-lock.jsonis present.I do the tests after building my docker images on my own and I always delete
package-lock.jsonbefore runningnpm installto be sure getting the newest deps. -
@karsten13 package-lock is SUPPOSED to insure installing EXACTLY those versions every time
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login