-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
install: fix install checks for optional/dev dependencies #76
Conversation
I'd like to get a review from @iarna on this one. |
In which version this this fix is going to be released? |
I'm not one for "me-too" posts, but I was extremely disappointed to see this didn't go into npm 6.5.0. It's preventing me and my team from making effective use of package-lock.json or submitting it to our source control. Is there anything the community can do to help move this patch along? As an OSS maintainer, I completely understand that things can sometimes fall through the cracks when it comes to waiting for someone to review them, but this seems like a fairly minimal, high-impact change to the source. |
This was merged as 1342071 and will be in the next release of npm (which will be the first or second week of January, schedules depending). I rewrote the test to be a bit more in our current style and take advantage of our test tooling. You can see the changes here: https://gist.github.com/iarna/ca94b7b044cd55c95753964aad27e4d2 |
@rooby Yes, see the previous comment. |
Is there any chance that npm v6.6 will be bundled with the next Node v10.x release? Say, v10.16... |
@khitrenovich it's being worked on: nodejs/node#25804 |
This would avoid generating excessive package-lock.json commits (fixed in npm/cli#76).
This would avoid generating excessive package-lock.json commits (fixed in npm/cli#76).
This patch updates node and npm to the latest LTS version which [should hopefully fix the package-lock.json problem](npm/cli#76 (comment)) although this is hard to verify. Worst case, we just upgraded npm.
Instead of creating a new set each time a new node gets visited, so that its siblings do not have it in `seen`, just remove the node from the original set right after all child nodes are visited. See npm#76
* chore: bump @npmcli/template-oss from 4.12.0 to 4.12.1 Bumps [@npmcli/template-oss](https://github.com/npm/template-oss) from 4.12.0 to 4.12.1. - [Release notes](https://github.com/npm/template-oss/releases) - [Changelog](https://github.com/npm/template-oss/blob/main/CHANGELOG.md) - [Commits](npm/template-oss@v4.12.0...v4.12.1) --- updated-dependencies: - dependency-name: "@npmcli/template-oss" dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> * chore: postinstall for dependabot template-oss PR --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: npm CLI robot <npm-cli+bot@github.com>
Problem: when a sub-dependency is required by an optional dependency in two different ways (e.g. once directly and once via another sub-dependency) the sub-dependency checking process ends up at the (optional) parent dependency twice, always failing the check.
Fix: make sure that the tracking of already seen packages has no effects on parallel paths.
See https://npm.community/t/2569