Hacker News new | ask | show | jobs
by vinceguidry 1968 days ago
It's been awhile since I've worked with npm, does it still do that thing where it changes package.json every time you `npm install`? I remember writing a script to discard package.json edits because my PR wasn't supposed to upgrade any libraries.
3 comments

I never recall it doing that, you may be thinking of the `package-lock.json` which does get created still. It basically creates/records hashes of the packages that get installed when `npm install` runs. Shouldn't always be changes there but depending on how version flags are set in `package.json` an `npm install` could create new `package-lock.json` values if there's a newer version in the repo that gets upgraded/installed.
We have a private local package repo at my company. Some developers set up their npm registry, or had it set up for them, with registry=https://.. Others have registry=http://...

Regardless of whether or not Strict-Transport-Security is enabled on the server, npm will still record the protocol as-is in the package-lock.json file.

Half the time a PR will include a package-lock.json with every "resolved" field having the protocol gratuitously changed to the other protocol.

We have a pretty similar issue at work where our package-lock file switches URLs between npmjs.com and our own npm registry. Can you elaborate a bit on what the issue is and how to solve it?
The issue is that some developers have configured the registry field in their .npmrc file incorrectly. Ideally, sending out a memo telling everyone to fix it should do it. If not, one way to fix it is to commit the .npmrc with the correct configuration (assuming it doesn't include secrets). If all else fails, an ugly hack is to make a preinstall hook that fixes the .npmrc file.
This is likely referring to the .npmrc registry field.
Yep.
This seems like a problem that could be solved with one email.
I think the story we're all commenting on demonstrates how unlikely a single email is going to fix it.
you have to use `npm ci`, which was added a few years ago. my team ran into that kind of issue right after `ci` was added, thankfully, or we would've had to do something similar.

i now have this aliased to `ni`, so i get to say `ni` to the app often.

Made my day :) Guess we'll adopt this.
Probably that was before package-lock.json (version pinning) was introduced?