Are you.. are you telling me .. that every time ..... every time ..... I've been running ..... npm i something .... it's been putting ^version into my ..... package.json file ?!?!?!?!!? SO THAT IN THE FUTURE WHEN I COME BACK TO THE PROJECT AND DO A FRESH NPM I .... THE VERSIONS WILL ALL UPDATE .... AND THAT'S WHY I'M ALWAYS DEALING WITH BUGS WHEN COMING BACK TO PROJECTS EVEN THOUGH IT WAS WORKING WHEN I LEFT IT A FEW MONTHS AGO.

FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU

Stop yelling

@Creep BUT IT'S A PISS OFF! WHY SHOULDN'T HE BE YELLING???

Yeah how awful...
Go eat something, it’ll make u feel better

what about putting @ instead of ^?

@melezorus34 🤔 I've heard of ^, *, and ~ but what does @ do?

@NoMad lol I somehow remembered it wrong, it's just "" instead of "@"

That is why package-lock.json exists and a reason why deployments use npm ci instead of npm install. The only bad thing about npm ci is that it always deletes whole node_modules folder making installation taking a while.

@arekxv but package-lock.json has such horrendous compatibility with git? Unless you can give me some pointers for committing package-lock effectively.

I've read about npm ci that's how I realised that versions are being prefixed with ^, IMO versions should just be whatever version is installed, not any version above that, that just seems like such a dumb and horrible idea to make a dependency allowed to be any version above the version that the user installed at a given point in time

@scout lmao

@NoMad ty :')

@melezorus34 You might be thinking of when you install a specific version using npm i, such as npm i package@version

the problem is that even when doing that, what gets put into package.json is the version prefixed by the ^ so later installs might install a newer version, it's absurd imo

@lopu Simple. Dont use npm install. It modifies package-lock by updating packages and ignoring package-lock most of the time. Use it only to add new or update existing packages.

When two people update / install all packages through npm install it modifies package-lock and you get a conflict.

npm ci follows package-lock only always reproducing exact versions of packages you initially installed. The only downside to it is that it takes a while so if you update frequently its a pain. yarn is a bit better in that regard but I think it also updates its lock file.

alright cool cool cheers I'll give it a shot

@arekxv oh boy this is gonna be difficult to unlearn, I might have to alias npm i to npm ci :') I manually delete node_modules all the time anyway because I'm paranoid of corruption

There is a '--save-exact' or '-E' cli option, but they just want you to learn it the hard way.

Back in the day I was dealing with some problems because even the fucking aws-sdk module was broken because of the fucking npm version ranges making the servers install the broken module version. Since then I use the 'save exact' param even for modules I'm just testing 😓

@JhonDoe seriously it should be on by default, it doesn't make sense

It's a very simplistic approach, but what I do is during development, when I generally DO want to be coding against the latest versions, I let NPM do its thing and I update frequently (usually at the start of each coding session) and re-run tests each time, fixing any issues. Then, when the code is ready for release or is otherwise "done", I simply go into package.json, remove all the ^'s, leaving just pristine, specific version numbers (I usually delete node_modules and package-lock.json too and then do a final install and re-run all tests, just to be safe). It's a bit more manual effort, but it allows me to be in control of my code rather than risking a breakage because I let NPM think for me.

@fzammetti great idea, I'm glad I've figured this out I thought I was going insane with my repositories breaking simply by leaving them to time...

@fzammetti That is risky. Using ^ on a version 2.3.4 will result in any version between 2.3.4 and 3.0.0. By removing the ^ you would be affixing to the exact version even though you might have worked and tested with a later version.

For instance you used ^2.3.4 and worked on your code for 2 months. During that time package maintainer released critical security fixes upping the package to 2.5.5. You worked on 2.5.5 effectively. Tested everything and then removed the ^. Causing npm to install 2.3.4 next time. If you want to affix versions, use the ones in your package-lock then set those directly and you wont have issues.

@arekxv good point

@arekxv You're exactly right, and I'm an idiot because when I wrote that comment I forgot that's precisely what I do, I don't just drop the ^ like I wrote for exactly the reason you say, I use the package-lock versions as you said (to be fair, it's been a little while since I've done that, but still, I should NOT have forgotten that key step, thanks for checking me!).