-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set Default npm
Version to 10 Under enable_corepack_for_npm_and_yarn Feature Flag
#10985
Conversation
end | ||
rescue JSON::ParserError | ||
NPM_DEFAULT_VERSION # Fallback to default npm version if parsing fails | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review Tip:
- When the
lockfileVersion
is 3 or higher, npm9
or npm10
could be selected. Since npm10
maintains compatibility with previous versions, we are opting for the latest version, npm10
. - When the
lockfileVersion
is 2, npm7
or npm8
could be chosen. However, given npm8
's compatibility with older versions, we are selecting the higher version, npm8
. - When the
lockfileVersion
is 1, npm6
is typically expected. However, if the feature flagnpm_fallback_version_above_v6
is enabled, we select npm8
instead. Currently, this feature flag is disabled, but it will be enabled after monitoring metrics.
In all other scenarios, we default to npm 10
, the latest version. If the lockfile cannot be parsed, npm 8
is used as a fallback version to ensure stability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kbukum1 : There is a bug in the logic for determining the appropriate npm version based on lockfile_version:
• Issue: If lockfile_version == 2, the current logic incorrectly assigns NPM_V10
instead of NPM_V8
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the logic is correct. Ignore me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am checking it but it seems to be npm 8? Are we looking in different place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a couple points of feedback but nothing blocking!
if lockfile_version.nil? | ||
NPM_V10 # Default if lockfileVersion is missing or nil | ||
elsif lockfile_version >= 3 | ||
NPM_V10 | ||
elsif lockfile_version >= 2 | ||
NPM_V8 | ||
elsif lockfile_version >= 1 | ||
Dependabot::Experiments.enabled?(:npm_fallback_version_above_v6) ? NPM_V8 : NPM_V6 | ||
else | ||
NPM_V10 # Fallback to npm 10 for unsupported or unexpected versions | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not really applicable at the moment, but as a personal preference I think this would be a little cleaner and easier to maintain as a hash if/when the experiment on npm_fallback_version_above_v6
is removed.
NPM_VERSION_FOR_LOCKFILE_VERSION={
1: NPM_V8,
2: NPM_V8,
3: NPM_V10,
}.freeze
return NPM_V10 unless NPM_VERSION_FOR_LOCKFILE_VERSION.has_key?(lockfile_version)
NPM_VERSION_FOR_LOCKFILE_VERSION[lockfile_version]
I think this would be identical to the description you gave below and covers the >= 3
, nil
and any other cases of not-explicitly set keys by returning V10.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, it's worth calling out that between the multiple experiment flags being used as well as the different "default" versions of V8 vs V10, it will be fairly confusing to manually debug what the expected npm version is in any specific case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After this fix, we plan to monitor metrics for npm 6 and eventually remove it entirely once the feature flag is enabled. At that time, I intend to make those adjustments. However, for now, this fix focuses on handling versions running on npm 8
instead of npm 10
. We are getting error because of running on npm 8
for some customers after the corepack fix, #10944
@@ -16,6 +16,7 @@ module Helpers | |||
/^.*(?<error>The "yarn-path" option has been set \(in [^)]+\), but the specified location doesn't exist)/ | |||
|
|||
# NPM Version Constants | |||
NPM_V10 = 10 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it necessary to define these constants here as integers and in npm_and_yarn/lib/dependabot/npm_and_yarn/package_manager.rb as strings? Could they be defined in one location and business logic makes the necessary conversion of number<->string as needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eventually, we’ll need to refactor this to define all versions as strings instead of integers. However, this cleanup will take place after we finish removing all feature flags related to versioning and deprecate the old ecosystem metrics collection. For now, the specs require the method to return an integer, and this change is outside the scope of the current issue.
@@ -1089,7 +1089,7 @@ | |||
let(:previous_requirements) { requirements } | |||
|
|||
it "raises a helpful error" do | |||
expect { updated_npm_lock_content }.to raise_error(Dependabot::DependencyFileNotResolvable) | |||
expect { updated_npm_lock_content }.to raise_error(Dependabot::InconsistentRegistryResponse) | |||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The error being thrown has changed because the lockfileVersion
for these dependency files is 3
. Previously, the spec used npm 8
, but with this update, it now defaults to npm 10
to align with the latest version for lockfileVersion
3 and above.
Example lockfile:
{
"name": "DependencyNotFound",
"version": "0.36.1",
"lockfileVersion": 3,
"requires": true,
"packages": {
"": {
"name": "DependencyNotFound",
"version": "0.36.1",
"license": "MIT",
"dependencies": {},
"devDependencies": {
"eslint": "^9.5.0"
},
"engines": {
"node": ">=12"
}
}
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are you trying to accomplish?
This PR addresses general issues with npm version detection and provides a robust solution to handle version determination based on the
package-lock.json
file. It updates theenable_corepack_for_npm_and_yarn
feature by setting the default npm version to 10 when the feature flag is enabled. Previously, the default npm version was set to 8. This update ensures compatibility with the latest npm features while solving broader problems related to npm version detection.Why is this change needed?
Anything you want to highlight for special attention from reviewers?
npm_version_numeric_latest
determines the npm version to use based on thelockfileVersion
field in thepackage-lock.json
file. It defaults to npm 10 in cases where the field is missing or invalid.npm_version_numeric
to callnpm_version_numeric_latest
when the feature flag is enabled.How will you know you've accomplished your goal?
enable_corepack_for_npm_and_yarn
feature flag.Checklist