Revert "prune: Fix bug where prune --production would remove dev deps… by bcomnes · Pull Request #166 · npm/cli

bcomnes · 2019-02-20T01:20:45Z

… from the lock file"

This change broke the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally (not what you would typically want ever). The only way around this was to prune --prod during prepack to generate a shrinkwrap without devDeps and publish with that (prior to this change going out). See people here discussing that workaround: (here here)

After this change, prune --prod no longer modifies the shrinkwrap file to remove devDeps. Reverting this commit restores the old behavior.

The situation is already looking like a hack but here are two alternative ideas:

Perhaps the commit in question IS correct, but a shrinkwrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json). This is not the current behavior now though.
Perhaps running npm shrinkwrap --prod should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). The goal isn't to prune node_modules, its to get my shrinkwrap file right.

I would propose we revert this change in the meantime so that this avenue isn’t broken, until the primary issue is resolved.

This reverts commit cec5be5.

workaround for those interested

During prepack: npm prune --prod && rm npm-shrinkwrap.json && npm shrinkwrap Generates the shrinkwrap without devDeps
During postpack: git checkout -- npm-shrinkwrap.json && npm i restores devDeps and reinstalls what was removed during the prune.

… from the lock file" This breaks the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally. The only way around this was to `prune --prod` during prepack to generate a shrinkwrap without devDeps and publish with that. After this change, `prune --prod` no longer modifies the shrinkwrap file to remove devDeps. The situation is already looking like a hack but: - Perhaps a shrink wrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json) - Perhaps running `npm shrinkwrap --prod` should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). Easier than above, but still possibly in hacksvill. I would propose we revert this change so that this avenue isn’t broken, until the primary issue is resolved. This reverts commit cec5be5.

…e lock file

zkat

Hey! Thanks for taking the time to put this together. After some discussion, it was decided that this isn't really the fix we would be looking for -- I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context, but I'd rather that specific bug gets fixed. Having devDeps in shrinkwrap is by design, since the shrinkwrap file is intended to be a complete description of the tree and we don't currently have plans to allow partial shrinkwraps (the way that used to be possible).

As such, we're gonna pass on this PR, but I hope you continue contributing in the future! (such as contributing a PR to fix that bug). The care is appreciated! ❤️

bcomnes · 2019-03-18T22:41:34Z

I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context

Do you have any advice on where to start a fix for that?

bcomnes · 2019-02-20T01:20:45Z

… from the lock file"

This change broke the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally (not what you would typically want ever). The only way around this was to prune --prod during prepack to generate a shrinkwrap without devDeps and publish with that (prior to this change going out). See people here discussing that workaround: (here here)

After this change, prune --prod no longer modifies the shrinkwrap file to remove devDeps. Reverting this commit restores the old behavior.

The situation is already looking like a hack but here are two alternative ideas:

Perhaps the commit in question IS correct, but a shrinkwrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json). This is not the current behavior now though.
Perhaps running npm shrinkwrap --prod should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). The goal isn't to prune node_modules, its to get my shrinkwrap file right.

I would propose we revert this change in the meantime so that this avenue isn’t broken, until the primary issue is resolved.

This reverts commit cec5be5.

workaround for those interested

During prepack: npm prune --prod && rm npm-shrinkwrap.json && npm shrinkwrap Generates the shrinkwrap without devDeps
During postpack: git checkout -- npm-shrinkwrap.json && npm i restores devDeps and reinstalls what was removed during the prune.

… from the lock file" This breaks the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally. The only way around this was to `prune --prod` during prepack to generate a shrinkwrap without devDeps and publish with that. After this change, `prune --prod` no longer modifies the shrinkwrap file to remove devDeps. The situation is already looking like a hack but: - Perhaps a shrink wrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json) - Perhaps running `npm shrinkwrap --prod` should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). Easier than above, but still possibly in hacksvill. I would propose we revert this change so that this avenue isn’t broken, until the primary issue is resolved. This reverts commit cec5be5.

…e lock file

zkat

Hey! Thanks for taking the time to put this together. After some discussion, it was decided that this isn't really the fix we would be looking for -- I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context, but I'd rather that specific bug gets fixed. Having devDeps in shrinkwrap is by design, since the shrinkwrap file is intended to be a complete description of the tree and we don't currently have plans to allow partial shrinkwraps (the way that used to be possible).

As such, we're gonna pass on this PR, but I hope you continue contributing in the future! (such as contributing a PR to fix that bug). The care is appreciated! ❤️

bcomnes · 2019-03-18T22:41:34Z

I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context

Do you have any advice on where to start a fix for that?

bcomnes · 2019-02-20T01:20:45Z

… from the lock file"

This change broke the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally (not what you would typically want ever). The only way around this was to prune --prod during prepack to generate a shrinkwrap without devDeps and publish with that (prior to this change going out). See people here discussing that workaround: (here here)

After this change, prune --prod no longer modifies the shrinkwrap file to remove devDeps. Reverting this commit restores the old behavior.

The situation is already looking like a hack but here are two alternative ideas:

Perhaps the commit in question IS correct, but a shrinkwrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json). This is not the current behavior now though.
Perhaps running npm shrinkwrap --prod should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). The goal isn't to prune node_modules, its to get my shrinkwrap file right.

I would propose we revert this change in the meantime so that this avenue isn’t broken, until the primary issue is resolved.

This reverts commit cec5be5.

workaround for those interested

During prepack: npm prune --prod && rm npm-shrinkwrap.json && npm shrinkwrap Generates the shrinkwrap without devDeps
During postpack: git checkout -- npm-shrinkwrap.json && npm i restores devDeps and reinstalls what was removed during the prune.

… from the lock file" This breaks the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally. The only way around this was to `prune --prod` during prepack to generate a shrinkwrap without devDeps and publish with that. After this change, `prune --prod` no longer modifies the shrinkwrap file to remove devDeps. The situation is already looking like a hack but: - Perhaps a shrink wrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json) - Perhaps running `npm shrinkwrap --prod` should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). Easier than above, but still possibly in hacksvill. I would propose we revert this change so that this avenue isn’t broken, until the primary issue is resolved. This reverts commit cec5be5.

…e lock file

zkat

Hey! Thanks for taking the time to put this together. After some discussion, it was decided that this isn't really the fix we would be looking for -- I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context, but I'd rather that specific bug gets fixed. Having devDeps in shrinkwrap is by design, since the shrinkwrap file is intended to be a complete description of the tree and we don't currently have plans to allow partial shrinkwraps (the way that used to be possible).

As such, we're gonna pass on this PR, but I hope you continue contributing in the future! (such as contributing a PR to fix that bug). The care is appreciated! ❤️

bcomnes · 2019-03-18T22:41:34Z

I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context

Do you have any advice on where to start a fix for that?

bcomnes · 2019-02-20T01:20:45Z

… from the lock file"

This change broke the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally (not what you would typically want ever). The only way around this was to prune --prod during prepack to generate a shrinkwrap without devDeps and publish with that (prior to this change going out). See people here discussing that workaround: (here here)

After this change, prune --prod no longer modifies the shrinkwrap file to remove devDeps. Reverting this commit restores the old behavior.

The situation is already looking like a hack but here are two alternative ideas:

Perhaps the commit in question IS correct, but a shrinkwrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json). This is not the current behavior now though.
Perhaps running npm shrinkwrap --prod should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). The goal isn't to prune node_modules, its to get my shrinkwrap file right.

I would propose we revert this change in the meantime so that this avenue isn’t broken, until the primary issue is resolved.

This reverts commit cec5be5.

workaround for those interested

During prepack: npm prune --prod && rm npm-shrinkwrap.json && npm shrinkwrap Generates the shrinkwrap without devDeps
During postpack: git checkout -- npm-shrinkwrap.json && npm i restores devDeps and reinstalls what was removed during the prune.

… from the lock file" This breaks the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally. The only way around this was to `prune --prod` during prepack to generate a shrinkwrap without devDeps and publish with that. After this change, `prune --prod` no longer modifies the shrinkwrap file to remove devDeps. The situation is already looking like a hack but: - Perhaps a shrink wrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json) - Perhaps running `npm shrinkwrap --prod` should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). Easier than above, but still possibly in hacksvill. I would propose we revert this change so that this avenue isn’t broken, until the primary issue is resolved. This reverts commit cec5be5.

…e lock file

zkat

Hey! Thanks for taking the time to put this together. After some discussion, it was decided that this isn't really the fix we would be looking for -- I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context, but I'd rather that specific bug gets fixed. Having devDeps in shrinkwrap is by design, since the shrinkwrap file is intended to be a complete description of the tree and we don't currently have plans to allow partial shrinkwraps (the way that used to be possible).

As such, we're gonna pass on this PR, but I hope you continue contributing in the future! (such as contributing a PR to fix that bug). The care is appreciated! ❤️

bcomnes · 2019-03-18T22:41:34Z

I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context

Do you have any advice on where to start a fix for that?

bcomnes · 2019-02-20T01:20:45Z

… from the lock file"

This change broke the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally (not what you would typically want ever). The only way around this was to prune --prod during prepack to generate a shrinkwrap without devDeps and publish with that (prior to this change going out). See people here discussing that workaround: (here here)

After this change, prune --prod no longer modifies the shrinkwrap file to remove devDeps. Reverting this commit restores the old behavior.

The situation is already looking like a hack but here are two alternative ideas:

Perhaps the commit in question IS correct, but a shrinkwrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json). This is not the current behavior now though.
Perhaps running npm shrinkwrap --prod should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). The goal isn't to prune node_modules, its to get my shrinkwrap file right.

I would propose we revert this change in the meantime so that this avenue isn’t broken, until the primary issue is resolved.

This reverts commit cec5be5.

workaround for those interested

During prepack: npm prune --prod && rm npm-shrinkwrap.json && npm shrinkwrap Generates the shrinkwrap without devDeps
During postpack: git checkout -- npm-shrinkwrap.json && npm i restores devDeps and reinstalls what was removed during the prune.

… from the lock file" This breaks the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally. The only way around this was to `prune --prod` during prepack to generate a shrinkwrap without devDeps and publish with that. After this change, `prune --prod` no longer modifies the shrinkwrap file to remove devDeps. The situation is already looking like a hack but: - Perhaps a shrink wrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json) - Perhaps running `npm shrinkwrap --prod` should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). Easier than above, but still possibly in hacksvill. I would propose we revert this change so that this avenue isn’t broken, until the primary issue is resolved. This reverts commit cec5be5.

…e lock file

zkat

Hey! Thanks for taking the time to put this together. After some discussion, it was decided that this isn't really the fix we would be looking for -- I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context, but I'd rather that specific bug gets fixed. Having devDeps in shrinkwrap is by design, since the shrinkwrap file is intended to be a complete description of the tree and we don't currently have plans to allow partial shrinkwraps (the way that used to be possible).

As such, we're gonna pass on this PR, but I hope you continue contributing in the future! (such as contributing a PR to fix that bug). The care is appreciated! ❤️

bcomnes · 2019-03-18T22:41:34Z

I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context

Do you have any advice on where to start a fix for that?

bcomnes · 2019-02-20T01:20:45Z

… from the lock file"

This change broke the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally (not what you would typically want ever). The only way around this was to prune --prod during prepack to generate a shrinkwrap without devDeps and publish with that (prior to this change going out). See people here discussing that workaround: (here here)

After this change, prune --prod no longer modifies the shrinkwrap file to remove devDeps. Reverting this commit restores the old behavior.

The situation is already looking like a hack but here are two alternative ideas:

Perhaps the commit in question IS correct, but a shrinkwrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json). This is not the current behavior now though.
Perhaps running npm shrinkwrap --prod should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). The goal isn't to prune node_modules, its to get my shrinkwrap file right.

I would propose we revert this change in the meantime so that this avenue isn’t broken, until the primary issue is resolved.

This reverts commit cec5be5.

workaround for those interested

During prepack: npm prune --prod && rm npm-shrinkwrap.json && npm shrinkwrap Generates the shrinkwrap without devDeps
During postpack: git checkout -- npm-shrinkwrap.json && npm i restores devDeps and reinstalls what was removed during the prune.

… from the lock file" This breaks the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally. The only way around this was to `prune --prod` during prepack to generate a shrinkwrap without devDeps and publish with that. After this change, `prune --prod` no longer modifies the shrinkwrap file to remove devDeps. The situation is already looking like a hack but: - Perhaps a shrink wrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json) - Perhaps running `npm shrinkwrap --prod` should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). Easier than above, but still possibly in hacksvill. I would propose we revert this change so that this avenue isn’t broken, until the primary issue is resolved. This reverts commit cec5be5.

…e lock file

zkat

Hey! Thanks for taking the time to put this together. After some discussion, it was decided that this isn't really the fix we would be looking for -- I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context, but I'd rather that specific bug gets fixed. Having devDeps in shrinkwrap is by design, since the shrinkwrap file is intended to be a complete description of the tree and we don't currently have plans to allow partial shrinkwraps (the way that used to be possible).

As such, we're gonna pass on this PR, but I hope you continue contributing in the future! (such as contributing a PR to fix that bug). The care is appreciated! ❤️

bcomnes · 2019-03-18T22:41:34Z

I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context

Do you have any advice on where to start a fix for that?

bcomnes · 2019-02-20T01:20:45Z

… from the lock file"

This change broke the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally (not what you would typically want ever). The only way around this was to prune --prod during prepack to generate a shrinkwrap without devDeps and publish with that (prior to this change going out). See people here discussing that workaround: (here here)

After this change, prune --prod no longer modifies the shrinkwrap file to remove devDeps. Reverting this commit restores the old behavior.

The situation is already looking like a hack but here are two alternative ideas:

Perhaps the commit in question IS correct, but a shrinkwrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json). This is not the current behavior now though.
Perhaps running npm shrinkwrap --prod should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). The goal isn't to prune node_modules, its to get my shrinkwrap file right.

I would propose we revert this change in the meantime so that this avenue isn’t broken, until the primary issue is resolved.

This reverts commit cec5be5.

workaround for those interested

During prepack: npm prune --prod && rm npm-shrinkwrap.json && npm shrinkwrap Generates the shrinkwrap without devDeps
During postpack: git checkout -- npm-shrinkwrap.json && npm i restores devDeps and reinstalls what was removed during the prune.

… from the lock file" This breaks the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally. The only way around this was to `prune --prod` during prepack to generate a shrinkwrap without devDeps and publish with that. After this change, `prune --prod` no longer modifies the shrinkwrap file to remove devDeps. The situation is already looking like a hack but: - Perhaps a shrink wrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json) - Perhaps running `npm shrinkwrap --prod` should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). Easier than above, but still possibly in hacksvill. I would propose we revert this change so that this avenue isn’t broken, until the primary issue is resolved. This reverts commit cec5be5.

…e lock file

zkat

Hey! Thanks for taking the time to put this together. After some discussion, it was decided that this isn't really the fix we would be looking for -- I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context, but I'd rather that specific bug gets fixed. Having devDeps in shrinkwrap is by design, since the shrinkwrap file is intended to be a complete description of the tree and we don't currently have plans to allow partial shrinkwraps (the way that used to be possible).

As such, we're gonna pass on this PR, but I hope you continue contributing in the future! (such as contributing a PR to fix that bug). The care is appreciated! ❤️

bcomnes · 2019-03-18T22:41:34Z

I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context

Do you have any advice on where to start a fix for that?

bcomnes · 2019-02-20T01:20:45Z

… from the lock file"

This change broke the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally (not what you would typically want ever). The only way around this was to prune --prod during prepack to generate a shrinkwrap without devDeps and publish with that (prior to this change going out). See people here discussing that workaround: (here here)

After this change, prune --prod no longer modifies the shrinkwrap file to remove devDeps. Reverting this commit restores the old behavior.

The situation is already looking like a hack but here are two alternative ideas:

Perhaps the commit in question IS correct, but a shrinkwrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json). This is not the current behavior now though.
Perhaps running npm shrinkwrap --prod should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). The goal isn't to prune node_modules, its to get my shrinkwrap file right.

I would propose we revert this change in the meantime so that this avenue isn’t broken, until the primary issue is resolved.

This reverts commit cec5be5.

workaround for those interested

During prepack: npm prune --prod && rm npm-shrinkwrap.json && npm shrinkwrap Generates the shrinkwrap without devDeps
During postpack: git checkout -- npm-shrinkwrap.json && npm i restores devDeps and reinstalls what was removed during the prune.

… from the lock file" This breaks the ability to (easily) create a shrinkwrap file that does not include devDeps. The current behavior of a package published with a shrinkwrap file that includes devDeps is that the devDeps get installed when the package is installed globally. The only way around this was to `prune --prod` during prepack to generate a shrinkwrap without devDeps and publish with that. After this change, `prune --prod` no longer modifies the shrinkwrap file to remove devDeps. The situation is already looking like a hack but: - Perhaps a shrink wrapped package should not install devDeps when installed as a dependency or global package (this seems the most correct and implied behavior described in https://docs.npmjs.com/files/shrinkwrap.json) - Perhaps running `npm shrinkwrap --prod` should remove the devDeps from the lock file (without pruning node_modules so its faster and can be restored by shrink-wrapping without the flag). Easier than above, but still possibly in hacksvill. I would propose we revert this change so that this avenue isn’t broken, until the primary issue is resolved. This reverts commit cec5be5.

…e lock file

zkat

Hey! Thanks for taking the time to put this together. After some discussion, it was decided that this isn't really the fix we would be looking for -- I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context, but I'd rather that specific bug gets fixed. Having devDeps in shrinkwrap is by design, since the shrinkwrap file is intended to be a complete description of the tree and we don't currently have plans to allow partial shrinkwraps (the way that used to be possible).

As such, we're gonna pass on this PR, but I hope you continue contributing in the future! (such as contributing a PR to fix that bug). The care is appreciated! ❤️

bcomnes · 2019-03-18T22:41:34Z

I agree that it's definitely a bug for devDeps to be installed when there's a shrinkwrap in a global context

Do you have any advice on where to start a fix for that?

bcomnes requested a review from a team as a code owner February 20, 2019 01:20

bcomnes referenced this pull request Feb 20, 2019
prune: Fix bug where prune --production would remove dev deps from th…
cec5be5
…e lock file

zkat reviewed Mar 18, 2019
View reviewed changes

zkat closed this Mar 18, 2019

bcomnes deleted the revert-prune-change branch March 18, 2019 22:41

fabio-looker mentioned this pull request Dec 10, 2019
Implement github actions looker-open-source/look-at-me-sideways#29
Closed

scizor666 mentioned this pull request Jun 2, 2020
**WIP** install: correctly exclude dev dependencies when using global and shrinkwrap #218
Closed

Mhmonicox mentioned this pull request Feb 15, 2023
[Snyk] Upgrade make-fetch-happen from 10.1.2 to 10.2.1 Mhmonicox/cli#7
Open

Mhmonicox mentioned this pull request Jun 1, 2023
[Snyk] Upgrade make-fetch-happen from 10.1.2 to 10.2.1 Mhmonicox/cli#12
Open

CALISOULB mentioned this pull request Nov 30, 2023
[Snyk] Fix for 1 vulnerabilities CALISOULB/cli#19
Open

This was referenced Nov 30, 2023
[Snyk] Fix for 1 vulnerabilities varmakarthik12/cli#30
Closed
[Snyk] Security upgrade make-fetch-happen from 8.0.14 to 11.0.0 varmakarthik12/cli#39
Closed

kevinjm39 mentioned this pull request Dec 19, 2023
[Snyk] Fix for 1 vulnerabilities kevinjm39/cli#19
Open

MrBrain295 mentioned this pull request Dec 19, 2023
[Snyk] Fix for 3 vulnerabilities MrBrain295/cli#12
Open

CALISOULB mentioned this pull request Dec 20, 2023
[Snyk] Fix for 1 vulnerabilities CALISOULB/cli#21
Open

snyk-ioBot mentioned this pull request Oct 22, 2024
[Snyk] Fix for 21 vulnerabilities Graybar-codespace/cli-3#100
Open

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

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Jul 11, 2026
📊 대시보드 데이터 업데이트 (npm#166)
572d40f

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Jul 11, 2026
📊 대시보드 데이터 업데이트 (npm#166)
d16b369

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

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