Fuck npm and its mess with dependencies 🙄

yep. at least it _kind of_ works :D

First time I installed the work project I watched the install script alter automatically the files in the dependencies to actually work.

As time goes on, the number of shits like these just increment

Not really, npm is cool it keeps my hard disk full!

Better than keeping unused storage ¯\_(ツ)_/¯

I'm not sure if this is a good practice or not, but I've learned to use "npm ci", instead of "npm install", after I clone an npm project, so it doesn't change the dependency tree when I install the dependencies to run it.

A fellow developer suggested we don't check package-lock.json into version control, apparently this is what they did in the places he previously worked at... but I think that defeats the purpose of a package lock.

@nururururu yeah I always check in lock files

@nururururu No.
Very much no. You lock down package versions, and thier specifics in the relevant files. Then commit them to the remote. every few weeks, release the locks, amd upgrade. See if something is broken, and then fix. relock when done. Make sure to sync the team - backmerging feature branches.

Without version locks you *will* get "it worked a week ago on my env! what happened??" + "dunno. works for me on my machine!" + "production is borked! rollback mow!"

@magicMirror @magicMirror I see, unlocking and upgrading every few weeks seems like a good measure to take. You mean "no, very much no" for not checking in package-lock into version control, right? From day one of programming Node.js by myself I googled whether to put commit that and I've always found the answer that it's recommended to commit it, including in npm's documentation.

I was quite surprised when this fellow dev suggested we don't put it in version control, but thankfully we already had package-lock.json checked in so we didn't change that.

@nururururu yup, package-lock to be included.
Can't believe I got it sorted out. Only cost me my sanity. Wonder whether pnpm would have been easier to handle...

@nururururu
for large projects, with more then one dev working on it - always better to commit the lock file. And set the version you use in the pacakge.json.

Small prototype projects with a single dev - you do you. No one cares.

The runtime (node/deno version) upgrade strategy, and package upgrade strategy depends on security factors, and what I call the "pain factor". It is how painfull is doing small upgrades, with small breaks every few weeks, vs the pain of upgrading once a year with big breaking changes.....

Advanced use: Cache the packages, on a local Docker repo server.

@magicMirror caching the packages, huh

I’ll have to look that up

@nururururu
I had to adapt this to the pipeline becuase of the "what if dev account gets hacked on npm" and/or "what if dev decided to remove his package from npm".

fucking 🤡🤡🤡🤡.