Read the statement by Michael Teeuw here.
Best practice 'package-lock.json' for modules
What is the best approach with the
The most common approach I see is that the
package-lock.jsonis included in the repository and
npm installis listed in the installation instructions. This has the disadvantage that the
package-lock.jsonis sometimes changed during the installation and the user then has later problems doing a normal
git pullto update the module.
I see two approaches that prevent this problem and wanted to know if you know of any others and what advantages or disadvantages you see in these approaches.
package-lock.jsonfrom the repository (by adding it to
npm ciinstead of
@KristjanESPERANTO well, the intent is to insure a particular library set. it works great on limited test environments.
like our automated tests.
it does not work in real life on all the platforms we run on
that is why my upgrade script will erase it before upgrading the code to prevent the changed file error.
but you can’t have it IN the repo for test,
NOT have it after git clone
npm ci doesn’t help
npm cidoesn’t help? It doesn’t change the
@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.
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
@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.