1

Our .npmrc file has the following to lock the runtime and dependencies to be exact versions:

#Make sure that we use the expected node and npm versions
engine-strict=true
save-exact=true

This mostly avoids the 'well, it's working on my computer issue' by writing exact version numbers in package.json.

However, I noticed that the transitive dependencies on npm install are still bringing in ^4.5.6 which re-opens the hole again. Is there a setting in .npmrc to make these fixed versions as well, so that all developers on the team are 100% on the same versions?

Specifically, when any developer runs npm install xxxx, it should never write any ^4.4.4 versions, transitive or not. The direct ones were fixed but transitive ones are still going into package.json as ^4.4.4. Over time, this leaves every developer on different versions of modules at the same git hash and we have a very hard time comparing different environments. Worse is when you check out code from 6 months ago and it uses different versions than you ran in production.

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
Dean Hiller
  • 19,235
  • 25
  • 129
  • 212
  • Does this answer your question? [How do I override nested NPM dependency versions?](https://stackoverflow.com/questions/15806152/how-do-i-override-nested-npm-dependency-versions) – jonrsharpe Feb 15 '22 at 14:46
  • Not really. I am trying to enforce this on the 'team' such if they do npm install xxxx, it does it without them knowing. If not, there will be additions in the future that will go missed and more ^4.6.7 will be added in package.json which is what I am trying to avoid "without having to manually check it all the time". ie. in java, I never have to check it and it just works and everyone is locked to the same version. – Dean Hiller Feb 15 '22 at 15:55
  • thank you for the try though @jonrsharpe! IT is appreciated. I read through nearly all the answers there to see if anyone had something close. – Dean Hiller Feb 15 '22 at 15:56
  • Then unless you only depend on packages that themselves have completely pinned dependencies and so on right to the leaves (relatively unusual in the ecosystem), no. If you're versioning the lockfile too you'll be able to `npm install`/`npm ci` and get a reproducible tree across your team (so you wouldn't get any "every developer on different versions"/"6 months ago"/"in production" problems), but `npm install ` _may_ cause a different version of an existing dependency to get resolved. – jonrsharpe Feb 15 '22 at 16:03
  • Note that this new version would be propagated across the team as they checked out the updated code and ran `npm install`, they _wouldn't_ have "different versions of modules at the same git hash". Also transitive dependencies _don't_ go into `package.json`, with carets or otherwise. – jonrsharpe Feb 15 '22 at 16:05
  • @DeanHiller thanks for posting this issue, I feel like it doesn't get enough attention. Anyone who's released software after days of rigorous testing only to realize that during the production build a transitive dependency was updated due to `^` syntax in the version, and it so happens to break portions of your UI, knows the pain... So the answer? Every once in a blue moon when I upgrade UI dependencies I let NPM generate a new `package-lock.json` and then I use an IDE (IntelliJ) to run a simple regex replace, searching for `": "[\^\~]([\d\.]+)"(,*)` and replacing with: `": "$1"$2` – ecoe Mar 13 '22 at 17:56

0 Answers0