Check save-prefix satisfies requested install version range by gosplit · Pull Request #193 · npm/cli

gosplit · 2019-04-26T09:01:52Z

The bug report is also opened in npm community.

In short, the recent Angular Compiler requires older typescript packages and asks users to run npm install typescript@">=3.1.1 <3.3"

However, after running the install command, package.json will be update to typescript@^3.2.4, which will still pull incompatible version, eg.'typescript@3.3.0' in other build machine. So I add some checks in computeVersionSpec to ensure adding the save-prefix ^ or ~ only when it satisfies requested version range.

isaacs · 2019-06-26T23:05:56Z

I think there's probably a better way to do this, but I get that this is a problem. If the user provides a complex range, and save-prefix + resolved version is not a subset of that range, then it's a problem. In that case, I'd prefer to save the range that the user provided, but of course that can run into issues if you do something like npm i foo@'>=1.0.0 or something, because you'll pick up a semver major without realizing it. Maybe that's fine, if that's what they want? This needs some more discussion, though.

gosplit · 2019-07-03T10:17:09Z

I agree with @isaacs. It's better if we can just save the user-provided range in the package.json file.
However, as labeled, this new implementation will break back-compatibility.
To compromise with the back-compatibility, maybe we can just try out [^,~,''] to find the first suitable save-prefix to save?

isaacs · 2020-09-11T18:37:56Z

npm/arborist#127

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005

@isaacs

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005 PR-URL: #145 Credit: @isaacsClose: #145 Reviewed-by: @isaacs

) load_from_disk used four nested if-let-Ok blocks that silently returned an empty HashMap on any failure. When the encryption key rotated or the cache file was corrupted, tokens silently stopped loading and users were forced to re-authenticate with no explanation. Replace with explicit match arms that log specific warnings to stderr for each failure mode: - Decryption failure (key changed, corrupted data) - Invalid UTF-8 in decrypted data - JSON deserialization failure File-not-found is still silent since that's normal on first run.

gosplit · 2019-04-26T09:01:52Z

The bug report is also opened in npm community.

In short, the recent Angular Compiler requires older typescript packages and asks users to run npm install typescript@">=3.1.1 <3.3"

However, after running the install command, package.json will be update to typescript@^3.2.4, which will still pull incompatible version, eg.'typescript@3.3.0' in other build machine. So I add some checks in computeVersionSpec to ensure adding the save-prefix ^ or ~ only when it satisfies requested version range.

isaacs · 2019-06-26T23:05:56Z

I think there's probably a better way to do this, but I get that this is a problem. If the user provides a complex range, and save-prefix + resolved version is not a subset of that range, then it's a problem. In that case, I'd prefer to save the range that the user provided, but of course that can run into issues if you do something like npm i foo@'>=1.0.0 or something, because you'll pick up a semver major without realizing it. Maybe that's fine, if that's what they want? This needs some more discussion, though.

gosplit · 2019-07-03T10:17:09Z

I agree with @isaacs. It's better if we can just save the user-provided range in the package.json file.
However, as labeled, this new implementation will break back-compatibility.
To compromise with the back-compatibility, maybe we can just try out [^,~,''] to find the first suitable save-prefix to save?

isaacs · 2020-09-11T18:37:56Z

npm/arborist#127

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005

@isaacs

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005 PR-URL: #145 Credit: @isaacsClose: #145 Reviewed-by: @isaacs

) load_from_disk used four nested if-let-Ok blocks that silently returned an empty HashMap on any failure. When the encryption key rotated or the cache file was corrupted, tokens silently stopped loading and users were forced to re-authenticate with no explanation. Replace with explicit match arms that log specific warnings to stderr for each failure mode: - Decryption failure (key changed, corrupted data) - Invalid UTF-8 in decrypted data - JSON deserialization failure File-not-found is still silent since that's normal on first run.

gosplit · 2019-04-26T09:01:52Z

The bug report is also opened in npm community.

In short, the recent Angular Compiler requires older typescript packages and asks users to run npm install typescript@">=3.1.1 <3.3"

However, after running the install command, package.json will be update to typescript@^3.2.4, which will still pull incompatible version, eg.'typescript@3.3.0' in other build machine. So I add some checks in computeVersionSpec to ensure adding the save-prefix ^ or ~ only when it satisfies requested version range.

isaacs · 2019-06-26T23:05:56Z

I think there's probably a better way to do this, but I get that this is a problem. If the user provides a complex range, and save-prefix + resolved version is not a subset of that range, then it's a problem. In that case, I'd prefer to save the range that the user provided, but of course that can run into issues if you do something like npm i foo@'>=1.0.0 or something, because you'll pick up a semver major without realizing it. Maybe that's fine, if that's what they want? This needs some more discussion, though.

gosplit · 2019-07-03T10:17:09Z

I agree with @isaacs. It's better if we can just save the user-provided range in the package.json file.
However, as labeled, this new implementation will break back-compatibility.
To compromise with the back-compatibility, maybe we can just try out [^,~,''] to find the first suitable save-prefix to save?

isaacs · 2020-09-11T18:37:56Z

npm/arborist#127

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005

@isaacs

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005 PR-URL: #145 Credit: @isaacsClose: #145 Reviewed-by: @isaacs

) load_from_disk used four nested if-let-Ok blocks that silently returned an empty HashMap on any failure. When the encryption key rotated or the cache file was corrupted, tokens silently stopped loading and users were forced to re-authenticate with no explanation. Replace with explicit match arms that log specific warnings to stderr for each failure mode: - Decryption failure (key changed, corrupted data) - Invalid UTF-8 in decrypted data - JSON deserialization failure File-not-found is still silent since that's normal on first run.

gosplit · 2019-04-26T09:01:52Z

The bug report is also opened in npm community.

In short, the recent Angular Compiler requires older typescript packages and asks users to run npm install typescript@">=3.1.1 <3.3"

However, after running the install command, package.json will be update to typescript@^3.2.4, which will still pull incompatible version, eg.'typescript@3.3.0' in other build machine. So I add some checks in computeVersionSpec to ensure adding the save-prefix ^ or ~ only when it satisfies requested version range.

isaacs · 2019-06-26T23:05:56Z

I think there's probably a better way to do this, but I get that this is a problem. If the user provides a complex range, and save-prefix + resolved version is not a subset of that range, then it's a problem. In that case, I'd prefer to save the range that the user provided, but of course that can run into issues if you do something like npm i foo@'>=1.0.0 or something, because you'll pick up a semver major without realizing it. Maybe that's fine, if that's what they want? This needs some more discussion, though.

gosplit · 2019-07-03T10:17:09Z

I agree with @isaacs. It's better if we can just save the user-provided range in the package.json file.
However, as labeled, this new implementation will break back-compatibility.
To compromise with the back-compatibility, maybe we can just try out [^,~,''] to find the first suitable save-prefix to save?

isaacs · 2020-09-11T18:37:56Z

npm/arborist#127

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005

@isaacs

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005 PR-URL: #145 Credit: @isaacsClose: #145 Reviewed-by: @isaacs

) load_from_disk used four nested if-let-Ok blocks that silently returned an empty HashMap on any failure. When the encryption key rotated or the cache file was corrupted, tokens silently stopped loading and users were forced to re-authenticate with no explanation. Replace with explicit match arms that log specific warnings to stderr for each failure mode: - Decryption failure (key changed, corrupted data) - Invalid UTF-8 in decrypted data - JSON deserialization failure File-not-found is still silent since that's normal on first run.

gosplit · 2019-04-26T09:01:52Z

The bug report is also opened in npm community.

In short, the recent Angular Compiler requires older typescript packages and asks users to run npm install typescript@">=3.1.1 <3.3"

However, after running the install command, package.json will be update to typescript@^3.2.4, which will still pull incompatible version, eg.'typescript@3.3.0' in other build machine. So I add some checks in computeVersionSpec to ensure adding the save-prefix ^ or ~ only when it satisfies requested version range.

isaacs · 2019-06-26T23:05:56Z

I think there's probably a better way to do this, but I get that this is a problem. If the user provides a complex range, and save-prefix + resolved version is not a subset of that range, then it's a problem. In that case, I'd prefer to save the range that the user provided, but of course that can run into issues if you do something like npm i foo@'>=1.0.0 or something, because you'll pick up a semver major without realizing it. Maybe that's fine, if that's what they want? This needs some more discussion, though.

gosplit · 2019-07-03T10:17:09Z

I agree with @isaacs. It's better if we can just save the user-provided range in the package.json file.
However, as labeled, this new implementation will break back-compatibility.
To compromise with the back-compatibility, maybe we can just try out [^,~,''] to find the first suitable save-prefix to save?

isaacs · 2020-09-11T18:37:56Z

npm/arborist#127

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005

@isaacs

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005 PR-URL: #145 Credit: @isaacsClose: #145 Reviewed-by: @isaacs

) load_from_disk used four nested if-let-Ok blocks that silently returned an empty HashMap on any failure. When the encryption key rotated or the cache file was corrupted, tokens silently stopped loading and users were forced to re-authenticate with no explanation. Replace with explicit match arms that log specific warnings to stderr for each failure mode: - Decryption failure (key changed, corrupted data) - Invalid UTF-8 in decrypted data - JSON deserialization failure File-not-found is still silent since that's normal on first run.

gosplit · 2019-04-26T09:01:52Z

The bug report is also opened in npm community.

In short, the recent Angular Compiler requires older typescript packages and asks users to run npm install typescript@">=3.1.1 <3.3"

However, after running the install command, package.json will be update to typescript@^3.2.4, which will still pull incompatible version, eg.'typescript@3.3.0' in other build machine. So I add some checks in computeVersionSpec to ensure adding the save-prefix ^ or ~ only when it satisfies requested version range.

isaacs · 2019-06-26T23:05:56Z

I think there's probably a better way to do this, but I get that this is a problem. If the user provides a complex range, and save-prefix + resolved version is not a subset of that range, then it's a problem. In that case, I'd prefer to save the range that the user provided, but of course that can run into issues if you do something like npm i foo@'>=1.0.0 or something, because you'll pick up a semver major without realizing it. Maybe that's fine, if that's what they want? This needs some more discussion, though.

gosplit · 2019-07-03T10:17:09Z

I agree with @isaacs. It's better if we can just save the user-provided range in the package.json file.
However, as labeled, this new implementation will break back-compatibility.
To compromise with the back-compatibility, maybe we can just try out [^,~,''] to find the first suitable save-prefix to save?

isaacs · 2020-09-11T18:37:56Z

npm/arborist#127

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005

@isaacs

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005 PR-URL: #145 Credit: @isaacsClose: #145 Reviewed-by: @isaacs

) load_from_disk used four nested if-let-Ok blocks that silently returned an empty HashMap on any failure. When the encryption key rotated or the cache file was corrupted, tokens silently stopped loading and users were forced to re-authenticate with no explanation. Replace with explicit match arms that log specific warnings to stderr for each failure mode: - Decryption failure (key changed, corrupted data) - Invalid UTF-8 in decrypted data - JSON deserialization failure File-not-found is still silent since that's normal on first run.

gosplit · 2019-04-26T09:01:52Z

The bug report is also opened in npm community.

In short, the recent Angular Compiler requires older typescript packages and asks users to run npm install typescript@">=3.1.1 <3.3"

However, after running the install command, package.json will be update to typescript@^3.2.4, which will still pull incompatible version, eg.'typescript@3.3.0' in other build machine. So I add some checks in computeVersionSpec to ensure adding the save-prefix ^ or ~ only when it satisfies requested version range.

isaacs · 2019-06-26T23:05:56Z

I think there's probably a better way to do this, but I get that this is a problem. If the user provides a complex range, and save-prefix + resolved version is not a subset of that range, then it's a problem. In that case, I'd prefer to save the range that the user provided, but of course that can run into issues if you do something like npm i foo@'>=1.0.0 or something, because you'll pick up a semver major without realizing it. Maybe that's fine, if that's what they want? This needs some more discussion, though.

gosplit · 2019-07-03T10:17:09Z

I agree with @isaacs. It's better if we can just save the user-provided range in the package.json file.
However, as labeled, this new implementation will break back-compatibility.
To compromise with the back-compatibility, maybe we can just try out [^,~,''] to find the first suitable save-prefix to save?

isaacs · 2020-09-11T18:37:56Z

npm/arborist#127

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005

@isaacs

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005 PR-URL: #145 Credit: @isaacsClose: #145 Reviewed-by: @isaacs

) load_from_disk used four nested if-let-Ok blocks that silently returned an empty HashMap on any failure. When the encryption key rotated or the cache file was corrupted, tokens silently stopped loading and users were forced to re-authenticate with no explanation. Replace with explicit match arms that log specific warnings to stderr for each failure mode: - Decryption failure (key changed, corrupted data) - Invalid UTF-8 in decrypted data - JSON deserialization failure File-not-found is still silent since that's normal on first run.

gosplit · 2019-04-26T09:01:52Z

The bug report is also opened in npm community.

In short, the recent Angular Compiler requires older typescript packages and asks users to run npm install typescript@">=3.1.1 <3.3"

However, after running the install command, package.json will be update to typescript@^3.2.4, which will still pull incompatible version, eg.'typescript@3.3.0' in other build machine. So I add some checks in computeVersionSpec to ensure adding the save-prefix ^ or ~ only when it satisfies requested version range.

isaacs · 2019-06-26T23:05:56Z

I think there's probably a better way to do this, but I get that this is a problem. If the user provides a complex range, and save-prefix + resolved version is not a subset of that range, then it's a problem. In that case, I'd prefer to save the range that the user provided, but of course that can run into issues if you do something like npm i foo@'>=1.0.0 or something, because you'll pick up a semver major without realizing it. Maybe that's fine, if that's what they want? This needs some more discussion, though.

gosplit · 2019-07-03T10:17:09Z

I agree with @isaacs. It's better if we can just save the user-provided range in the package.json file.
However, as labeled, this new implementation will break back-compatibility.
To compromise with the back-compatibility, maybe we can just try out [^,~,''] to find the first suitable save-prefix to save?

isaacs · 2020-09-11T18:37:56Z

npm/arborist#127

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005

@isaacs

If a user installs `foo@1.x <1.2.3`, and we resolve to `1.2.2`, then we should not save it as `^1.2.2`, since that would allow versions outside of the requested range. Explicit versions and tags are still saved using the savePrefix, since those are not ranges, and users can set `--save-exact` if they wish it to be saved exactly. Fix: #127Fix: npm/cli#193 Fix: https://npm.community/t/7005 PR-URL: #145 Credit: @isaacsClose: #145 Reviewed-by: @isaacs

) load_from_disk used four nested if-let-Ok blocks that silently returned an empty HashMap on any failure. When the encryption key rotated or the cache file was corrupted, tokens silently stopped loading and users were forced to re-authenticate with no explanation. Replace with explicit match arms that log specific warnings to stderr for each failure mode: - Decryption failure (key changed, corrupted data) - Invalid UTF-8 in decrypted data - JSON deserialization failure File-not-found is still silent since that's normal on first run.

gosplit requested a review from a team as a code owner April 26, 2019 09:01

gosplit force-pushed the save-prefix-according-range-requested branch from 729c369 to 442a88bCompare May 13, 2019 06:11

check save-prefix satisfies requested version range
3042e1a

gosplit force-pushed the save-prefix-according-range-requested branch from 442a88b to 3042e1aCompare May 13, 2019 08:05

isaacs added semver:major backwards-incompatible breaking changes needs-discussion labels Jun 26, 2019

settingsBot removed the needs-discussion label Nov 5, 2019

darcyclarke added Needs Discussion is pending a discussion Needs Review Release 7.x work is associated with a specific npm 7 release labels Jul 31, 2020

darcyclarke assigned isaacs Jul 31, 2020

isaacs mentioned this pull request Sep 11, 2020
[BUG] only use savePrefix+version if that's a subset of the supplied version range npm/arborist#127
Closed

isaacs closed this Sep 11, 2020

isaacs mentioned this pull request Sep 28, 2020
Save provided range if not a subset of savePrefix npm/arborist#145
Closed

Theo13111 mentioned this pull request Aug 20, 2023
[Snyk] Upgrade npm-registry-fetch from 14.0.5 to 15.0.0 Theo13111/cli#120
Open

gutwrinch mentioned this pull request Oct 19, 2023
[Snyk] Upgrade npm-registry-fetch from 14.0.5 to 16.0.0 gutwrinch/cli-1#1
Merged

soloinovator mentioned this pull request Feb 11, 2024
[Snyk] Security upgrade npm-registry-fetch from 13.3.1 to 15.0.0 soloinovator/cli#32
Open

kevinjm39 mentioned this pull request Feb 11, 2024
[Snyk] Security upgrade npm-registry-fetch from 13.3.1 to 15.0.0 kevinjm39/cli#20
Open

hojatA1 mentioned this pull request Feb 11, 2024
[Snyk] Fix for 1 vulnerabilities hojatA1/npm.cli#91
Open

311821105 mentioned this pull request Feb 11, 2024
[Snyk] Fix for 1 vulnerabilities 311821105/cli#48
Open

mtdev2 mentioned this pull request Feb 11, 2024
[Snyk] Fix for 1 vulnerabilities mtdev2/cli#93
Open

311821105 mentioned this pull request Feb 11, 2024
[Snyk] Security upgrade npm-registry-fetch from 14.0.5 to 15.0.0 311821105/cli#50
Open

CALISOULB mentioned this pull request Feb 11, 2024
[Snyk] Fix for 1 vulnerabilities CALISOULB/cli#22
Open

adamlaska mentioned this pull request Feb 11, 2024
[Snyk] Security upgrade npm-registry-fetch from 13.3.1 to 15.0.0 adamlaska/cli-3#24
Open

EMWickd mentioned this pull request Feb 12, 2024
[Snyk] Security upgrade npm-registry-fetch from 14.0.5 to 15.0.0 EMWickd/cli#100
Open

Billywildhig mentioned this pull request Feb 12, 2024
[Snyk] Security upgrade npm-registry-fetch from 14.0.5 to 15.0.0 Billywildhig/cli#71
Open

kevinjm39 mentioned this pull request Feb 12, 2024
[Snyk] Security upgrade npm-registry-fetch from 13.3.1 to 15.0.0 kevinjm39/cli#28
Open

311821105 mentioned this pull request Feb 12, 2024
[Snyk] Fix for 1 vulnerabilities 311821105/cli#56
Open

LadyK-21 mentioned this pull request Feb 12, 2024
[Snyk] Security upgrade npm-registry-fetch from 13.3.1 to 15.0.0 LadyK-21/cli#34
Open

This was referenced Feb 12, 2024
[Snyk] Security upgrade npm-registry-fetch from 14.0.5 to 15.0.0 jackromo888/cli-1#18
Open
[Snyk] Security upgrade npm-registry-fetch from 14.0.5 to 15.0.0 jackromo888/cli-1#19
Open

This was referenced Feb 12, 2024
[Snyk] Security upgrade npm-registry-fetch from 14.0.5 to 15.0.0 Billywildhig/cli#75
Open
[Snyk] Fix for 1 vulnerabilities Billywildhig/cli#76
Open

kingjay66 mentioned this pull request Feb 12, 2024
[Snyk] Fix for 1 vulnerabilities kingjay66/cli-1#18
Open

adamlaska mentioned this pull request Feb 12, 2024
[Snyk] Security upgrade npm-registry-fetch from 13.3.1 to 15.0.0 adamlaska/cli-3#34
Open

EMWickd mentioned this pull request Feb 12, 2024
[Snyk] Security upgrade npm-registry-fetch from 14.0.5 to 15.0.0 EMWickd/cli#101
Open

This was referenced Feb 12, 2024
[Snyk] Fix for 1 vulnerabilities nicholaschoi168/cli#23
Open
[Snyk] Fix for 1 vulnerabilities nicholaschoi168/cli#25
Open
[Snyk] Fix for 1 vulnerabilities nicholaschoi168/cli#27
Open

This was referenced Feb 12, 2024
[Snyk] Fix for 1 vulnerabilities f4lco0n/npm-cli#36
Open
[Snyk] Fix for 1 vulnerabilities f4lco0n/npm-cli#37
Open
[Snyk] Fix for 1 vulnerabilities f4lco0n/npm-cli#39
Open

jackromo888 mentioned this pull request Feb 12, 2024
[Snyk] Fix for 1 vulnerabilities jackromo888/cli-1#21
Open

soloinovator mentioned this pull request Feb 12, 2024
[Snyk] Security upgrade npm-registry-fetch from 13.3.1 to 15.0.0 soloinovator/cli#41
Open

EMWickd mentioned this pull request Feb 12, 2024
[Snyk] Fix for 1 vulnerabilities EMWickd/cli#102
Open

soloinovator mentioned this pull request Feb 12, 2024
[Snyk] Security upgrade npm-registry-fetch from 13.3.1 to 15.0.0 soloinovator/cli#42
Open

TheManager73 mentioned this pull request Feb 12, 2024
[Snyk] Fix for 1 vulnerabilities TheManager73/cli#21
Open

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

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

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Jul 17, 2026
📊 blog1 게시 완료 (npm#193)
eba36e1

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Jul 17, 2026
📊 blog2 게시 완료 (npm#193)
0fab84a

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Jul 17, 2026
📊 blog3 게시 완료 (npm#193)
e90a8ae

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