Actually `npm` is doing exactly what I would expect. Mind you that the goal of `package-lock.json` is to minimize any changes in the (transitive) dependencies that were not explicitly requested.
- In Step 1, `request` is resolved to `2.79.0` since that version is pinned in `cordova-lib@8` and valid for the range `^2.74.0` given in `insight`, which we depend on. This is then saved to `package-lock.json`. - In Step 2, when we update `cordova-lib` to a version that does not depend on `request` anymore, our resolved dependency to request still satisfies what is requested by `insight`. So it stays the way it is. Again, this is what the lock file is for. We did *not* request any updates to be made apart from `cordova-lib`. Instead, npm tells us how to perform the minimal update necessary to solve the audit issues it found (either `npm audit fix` or `npm update request --depth 2`). I think that's a good thing. Of course, if you want to resolve the whole dependency tree again and do as many updates as possible, then deleting the lock file and regenerating it is a valid approach. Granted, it's a little bit extra work, but for that you only update stuff when you explicitly want to. I just recently spent a few hours going half-crazy when, unbeknownst to me, `jasmine` was updated from `3.1.0` to `3.2.0` and suddenly a bunch of tests in `cordova-lib` that worked fine previously just started to fail. That's exactly the thing that `package-lock.json` tries to avoid. [ Full content available at: https://github.com/apache/cordova-cli/pull/325 ] This message was relayed via gitbox.apache.org for [email protected]
