install: fix install checks for optional/dev dependencies by larsgw · Pull Request #76 · npm/cli

larsgw · 2018-10-08T14:00:03Z

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

See 36dd559

See c81df49

zkat · 2018-11-13T15:03:29Z

I'd like to get a review from @iarna on this one.

surmacz · 2018-11-23T09:15:18Z

In which version this this fix is going to be released?

mramato · 2018-12-11T15:23:12Z

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.

iarna · 2018-12-20T02:11:11Z

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 · 2019-01-29T23:55:30Z

None of the recent release notes seem to have a link to this pull request. Did it make it into 6.6.0 or 6.7.0?

Was it this one in 6.6?

1342071 npm.community#2569 Fix checking for optional dependencies. (@larsgw)

andersk · 2019-01-30T00:29:34Z

@rooby Yes, see the previous comment.

khitrenovich · 2019-02-14T03:49:42Z

Is there any chance that npm v6.6 will be bundled with the next Node v10.x release? Say, v10.16...

larsgw · 2019-02-14T16:38:25Z

@khitrenovich it's being worked on: nodejs/node#25804

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

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

* 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>

larsgw · 2018-10-08T14:00:03Z

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

See 36dd559

See c81df49

zkat · 2018-11-13T15:03:29Z

I'd like to get a review from @iarna on this one.

surmacz · 2018-11-23T09:15:18Z

In which version this this fix is going to be released?

mramato · 2018-12-11T15:23:12Z

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.

iarna · 2018-12-20T02:11:11Z

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 · 2019-01-29T23:55:30Z

None of the recent release notes seem to have a link to this pull request. Did it make it into 6.6.0 or 6.7.0?

Was it this one in 6.6?

1342071 npm.community#2569 Fix checking for optional dependencies. (@larsgw)

andersk · 2019-01-30T00:29:34Z

@rooby Yes, see the previous comment.

khitrenovich · 2019-02-14T03:49:42Z

Is there any chance that npm v6.6 will be bundled with the next Node v10.x release? Say, v10.16...

larsgw · 2019-02-14T16:38:25Z

@khitrenovich it's being worked on: nodejs/node#25804

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

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

* 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>

larsgw · 2018-10-08T14:00:03Z

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

See 36dd559

See c81df49

zkat · 2018-11-13T15:03:29Z

I'd like to get a review from @iarna on this one.

surmacz · 2018-11-23T09:15:18Z

In which version this this fix is going to be released?

mramato · 2018-12-11T15:23:12Z

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.

iarna · 2018-12-20T02:11:11Z

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 · 2019-01-29T23:55:30Z

None of the recent release notes seem to have a link to this pull request. Did it make it into 6.6.0 or 6.7.0?

Was it this one in 6.6?

1342071 npm.community#2569 Fix checking for optional dependencies. (@larsgw)

andersk · 2019-01-30T00:29:34Z

@rooby Yes, see the previous comment.

khitrenovich · 2019-02-14T03:49:42Z

Is there any chance that npm v6.6 will be bundled with the next Node v10.x release? Say, v10.16...

larsgw · 2019-02-14T16:38:25Z

@khitrenovich it's being worked on: nodejs/node#25804

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

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

* 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>

larsgw · 2018-10-08T14:00:03Z

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

See 36dd559

See c81df49

zkat · 2018-11-13T15:03:29Z

I'd like to get a review from @iarna on this one.

surmacz · 2018-11-23T09:15:18Z

In which version this this fix is going to be released?

mramato · 2018-12-11T15:23:12Z

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.

iarna · 2018-12-20T02:11:11Z

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 · 2019-01-29T23:55:30Z

None of the recent release notes seem to have a link to this pull request. Did it make it into 6.6.0 or 6.7.0?

Was it this one in 6.6?

1342071 npm.community#2569 Fix checking for optional dependencies. (@larsgw)

andersk · 2019-01-30T00:29:34Z

@rooby Yes, see the previous comment.

khitrenovich · 2019-02-14T03:49:42Z

Is there any chance that npm v6.6 will be bundled with the next Node v10.x release? Say, v10.16...

larsgw · 2019-02-14T16:38:25Z

@khitrenovich it's being worked on: nodejs/node#25804

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

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

* 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>

larsgw · 2018-10-08T14:00:03Z

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

See 36dd559

See c81df49

zkat · 2018-11-13T15:03:29Z

I'd like to get a review from @iarna on this one.

surmacz · 2018-11-23T09:15:18Z

In which version this this fix is going to be released?

mramato · 2018-12-11T15:23:12Z

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.

iarna · 2018-12-20T02:11:11Z

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 · 2019-01-29T23:55:30Z

None of the recent release notes seem to have a link to this pull request. Did it make it into 6.6.0 or 6.7.0?

Was it this one in 6.6?

1342071 npm.community#2569 Fix checking for optional dependencies. (@larsgw)

andersk · 2019-01-30T00:29:34Z

@rooby Yes, see the previous comment.

khitrenovich · 2019-02-14T03:49:42Z

Is there any chance that npm v6.6 will be bundled with the next Node v10.x release? Say, v10.16...

larsgw · 2019-02-14T16:38:25Z

@khitrenovich it's being worked on: nodejs/node#25804

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

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

* 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>

larsgw · 2018-10-08T14:00:03Z

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

See 36dd559

See c81df49

zkat · 2018-11-13T15:03:29Z

I'd like to get a review from @iarna on this one.

surmacz · 2018-11-23T09:15:18Z

In which version this this fix is going to be released?

mramato · 2018-12-11T15:23:12Z

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.

iarna · 2018-12-20T02:11:11Z

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 · 2019-01-29T23:55:30Z

None of the recent release notes seem to have a link to this pull request. Did it make it into 6.6.0 or 6.7.0?

Was it this one in 6.6?

1342071 npm.community#2569 Fix checking for optional dependencies. (@larsgw)

andersk · 2019-01-30T00:29:34Z

@rooby Yes, see the previous comment.

khitrenovich · 2019-02-14T03:49:42Z

Is there any chance that npm v6.6 will be bundled with the next Node v10.x release? Say, v10.16...

larsgw · 2019-02-14T16:38:25Z

@khitrenovich it's being worked on: nodejs/node#25804

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

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

* 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>

larsgw · 2018-10-08T14:00:03Z

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

See 36dd559

See c81df49

zkat · 2018-11-13T15:03:29Z

I'd like to get a review from @iarna on this one.

surmacz · 2018-11-23T09:15:18Z

In which version this this fix is going to be released?

mramato · 2018-12-11T15:23:12Z

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.

iarna · 2018-12-20T02:11:11Z

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 · 2019-01-29T23:55:30Z

None of the recent release notes seem to have a link to this pull request. Did it make it into 6.6.0 or 6.7.0?

Was it this one in 6.6?

1342071 npm.community#2569 Fix checking for optional dependencies. (@larsgw)

andersk · 2019-01-30T00:29:34Z

@rooby Yes, see the previous comment.

khitrenovich · 2019-02-14T03:49:42Z

Is there any chance that npm v6.6 will be bundled with the next Node v10.x release? Say, v10.16...

larsgw · 2019-02-14T16:38:25Z

@khitrenovich it's being worked on: nodejs/node#25804

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

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

* 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>

larsgw · 2018-10-08T14:00:03Z

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

See 36dd559

See c81df49

zkat · 2018-11-13T15:03:29Z

I'd like to get a review from @iarna on this one.

surmacz · 2018-11-23T09:15:18Z

In which version this this fix is going to be released?

mramato · 2018-12-11T15:23:12Z

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.

iarna · 2018-12-20T02:11:11Z

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 · 2019-01-29T23:55:30Z

None of the recent release notes seem to have a link to this pull request. Did it make it into 6.6.0 or 6.7.0?

Was it this one in 6.6?

1342071 npm.community#2569 Fix checking for optional dependencies. (@larsgw)

andersk · 2019-01-30T00:29:34Z

@rooby Yes, see the previous comment.

khitrenovich · 2019-02-14T03:49:42Z

Is there any chance that npm v6.6 will be bundled with the next Node v10.x release? Say, v10.16...

larsgw · 2019-02-14T16:38:25Z

@khitrenovich it's being worked on: nodejs/node#25804

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

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

@larsgw

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 #76 Credit: @larsgw PR-URL: #206Close: #206 Reviewed-by: @isaacs

* 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>

larsgw added 3 commits October 7, 2018 22:40

install: fix checking for optional dep
c81df49
See https://npm.community/t/2569

test: fix install check for optional deps
36dd559

test: future-proof install test
7390cd8
See 36dd559

larsgw requested a review from a team as a code owner October 8, 2018 14:00

larsgw added 2 commits October 8, 2018 21:51

install: fix checking for dev dep
2081556
See c81df49

test: checking for dev dep
63d5065

larsgw changed the title ~~install: fix install checks for optional dependencies~~install: fix install checks for optional/dev dependenciesOct 8, 2018

lucasfeliciano approved these changes Oct 11, 2018
View reviewed changes

stefee mentioned this pull request Oct 12, 2018
package-lock.json changes after merging a Renovate PR and running npm install renovatebot/renovate#2294
Closed

feelepxyz mentioned this pull request Oct 29, 2018
npm 'optional' fights dependabot/feedback#197
Closed

test: check pkglock is updated correctly
26e3e2a

chris48s mentioned this pull request Nov 9, 2018
Rework GitHub acceptor and move to its own module badges/shields#2021
Merged

zkat added semver:patch semver patch level for changes needs-discussion labels Nov 13, 2018

compulim mentioned this pull request Dec 7, 2018
Use npm ci for Travis CI build microsoft/BotFramework-WebChat#1449
Merged

iarna closed this Dec 20, 2018

cwhitten mentioned this pull request Dec 22, 2018
Bump botframework-directlinejs in all packages/samples microsoft/BotFramework-WebChat#1538
Closed

This was referenced Feb 22, 2019
Upgrades Node version 6.11.0 -> 10.15.1 freedomofpress/securedrop.org#598
Merged
Upgrades Node version 6.11.0 -> 10.15.1 freedomofpress/securethenews#179
Merged

zypA13510 added a commit to zypA13510/ui5-fontawesome that referenced this pull request Jun 7, 2019
ci: switch to node v10
5c5d225
This would avoid generating excessive package-lock.json commits (fixed in npm/cli#76).

zypA13510 added a commit to zypA13510/ui5-fontawesome that referenced this pull request Jun 7, 2019
ci: switch to node v10
d688427
This would avoid generating excessive package-lock.json commits (fixed in npm/cli#76).

lkiesow mentioned this pull request Jun 19, 2019
MH-13638, Update NPM opencast/opencast#975
Merged

larsgw mentioned this pull request Jul 1, 2019
install: improve isOnly(Dev,Optional) #206
Closed

kimadeline mentioned this pull request Sep 16, 2019
Update the minimal version of node/npm used in the repo microsoft/vscode-python#7426
Closed

This was referenced Sep 29, 2022
[Snyk] Fix for 21 vulnerabilities bumplzz69/cli#28
Open
[Snyk] Fix for 21 vulnerabilities bumplzz69/cli#29
Open
[Snyk] Fix for 21 vulnerabilities bumplzz69/cli#30
Open

bumplzz69 mentioned this pull request Oct 9, 2022
[Snyk] Fix for 21 vulnerabilities bumplzz69/cli#31
Open

311821105 mentioned this pull request May 13, 2023
[Snyk] Upgrade retry from 0.12.0 to 0.13.1 311821105/cli#2
Open

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Jul 1, 2026
🤖 봇 응답 (npm#76)
fdd1a0e

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Jul 10, 2026
🔧 자동 수리 완료 (npm#76)
20a922b

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Aug 2, 2026
🔥 트렌드 선점 후보 갱신 (npm#76)
73f6a56