Transitive dependencies matching the upgraded direct dependency dropped from lockfile #250
Comments
noahsilas
added a commit
to noahsilas/parse-server
that referenced
this issue
Mar 18, 2020
It's not clear what happened in parse-community#6478, but it appears that it dropped the `ws` dependency of the `parse` package when it was updating the local version of the dependency. This means that running `npm install` dirties the working tree, which is surprising! I've filed an issue for the surprising behavior from greenkeeper: greenkeeperio/greenkeeper-lockfile#250
noahsilas
added a commit
to noahsilas/parse-server
that referenced
this issue
Mar 18, 2020
It's not clear what happened in parse-community#6478, but it appears that it dropped the `ws` dependency of the `parse` package when it was updating the local version of the dependency. This means that running `npm install` dirties the working tree, which is surprising! A similar problem seems to have occurred in parse-community#6504, that time related to the `commander` package. I've filed an issue for the surprising behavior from greenkeeper: greenkeeperio/greenkeeper-lockfile#250
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Examples:
parse-community/parse-server#6478
In this PR, a direct dependency on
wswas updated from 7.2.1 to 7.2.2. The dependencyparseshould also rely on[email protected], but that dependency was removed from the lockfile.parse-community/parse-server#6504
In this PR, a direct dependency on
commanderwas updated from 4.1.1 to 5.0.0. The direct dependency was updated correctly, but two other dependencies hadcommander@^4.0.1removed from their dependency lists (@babel/cliandlint-stagedboth depended on it).In this second case, there wasn't even an exact match on the type field, but it does look like they had been resolving to the same version.
The text was updated successfully, but these errors were encountered: