don't gitignore your lock files!

[@feldinho]

The best way to learn the value of a lock file is to use pip for a while. Python projects are infamous for pinning everything. Once you have to upgrade anything, it’s up to you to find out a combination of packages that work.

[@ithinkimhipster502]

Pip-compile helps with that

[@scottfwalter]

Sadly, there are a lot of open source projects that don't understand semantic versioning. Introducing breaking changes/bugs in patch releases. npm ci is your friend.

[@cahva2]

This. We pin the version just for this. And on the security side, let's say the maintainer got social hacked, we will be safe as we wiil be cemented to the actual version until we update.

[@SoreBrain]

It's dependencies all the way down? Always has been 🔫

[@RBXTrains]

Those sub dependency requirements are a nightmare. Quite a few times our old underfunded stack has an old build pipeline stop working as a change has occurred with syntax specific to newer ECMAScript versions (usually optional chaining operator).... but we're still on node 14 so breaks. Would be massive workload to upgrade everything as using tonnes of now unsupported modules, and most of us a primarily Java developers lol

[@4v4]

very few packages actually follow proper versioning. it’s wild that something like tailwind has to just trust all its nested dependencies, assuming they’ll stick to semantic versioning

[@futuremoe]

Also don't forget to use npm ci in a CI pipeline to install from the lock file. Yarn and pnpm should do this automatically or take an env var.

[@RemotHuman]

deleting an regenerating your lock files updates your package versions. if you don't periodically do this, you could miss out on important security updates but if you do periodically do it, you could be vulnerable to supply chain attacks from a library updating maliciously, or bugs from it updating badly so I guess you are supposed to periodically do it and then (do your best to) check if any of your libraries turned evil when you do it Is that right?

[@linchen5913]

What an useful content. Thank you!

[@borisbrestnichki]

Pinning your deps across multiple developers and environments can be done by running a "clean install" (for npm is "npm ci") both in dev and ci. It'll not try to get newer versions including of deps of deps. And this needs the lock file, so don't ignore it. Rather challenge changes to the lock file in any "feature" MR and do a dedicated "upgrade" MRs.

[@matthewmoon2463]

Running npm audit is good practice for identifying vulnerabilities, but it doesn’t solve the problem of having a consistent, pinned dependency tree.

[@justingiovanetti]

9 times out of 10 when things don’t work, I just delete the lock file, and npm install again. And things just seem to work.

[@noriller]

i believe, if you pin dependencies, then it will pin dependencies of dependencies versions also. just tested on a old version of create vite with dependencies pinned and "^" there's a lot of differences there. then again, it probably also depends on the lockfile being there.

[@OtcSkater]

I thought so too.. so would it just act as if the caret was just removed all the way down?

[@yogenp]

One of the engineers I worked with was really offended when I said package-lock shouldn't be gitignored.

[@timonjur]

What's certainly human-readable is the pnpm-lock.yaml file!

[@ShaneCodes]

I just want the package json to update with what was installed. Like if I put v ^4.2.0 and it installs 4.5.0 I don't want to have to dig through the package-lock.json

[@codeman99-dev]

4:25 Users of npm should prefer to use `npm install --package-lock-only` to resolve conflicts.

[@dohnjoe342]

I have a continuous determination to explain to so-called Javascript experts the difference about npm install and npm ci and the purpose of the lock file and I will do until I am breathing. 😀

[@trappedcat3615]

The key is the word depend is not depinned

[@kissu_io]

Also what's the problem with committing a non readable file to begin with? It's just faster to not rebuild the entire tree all the time. 👍🏻 Even better: skip the build step whatsoever and stop relying on crazy amount of dependencies.

[@petecapecod]

Carrots 🥕 ^^ for life! 🤣 Thanks for the tips 👍🏻

[@elierh442]

The world runs on dependencies...

[@shinebayar]

Jokes on you, `npm install` doesn't use lock file anyways :)

[@Ss-zg3yj]

Poor BroccoliBoy69

[@ipanasenko]

Don't nuke lock files, at least yarn.lock! Yarn resolves conflicts in yarn.lock automatically during `yarn install`, don't know what other managers do with them though

[@shubhamnagota]

video

[@ydkme-reborn]

Lol