Skip to content
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.

Sign up for GitHub

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

feat(replacements): add replacements:gradle-wrapper-validation-action #31645

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
+13 −0
Open

feat(replacements): add replacements:gradle-wrapper-validation-action #31645

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
657c5b6
feat(replacements): add replacements:gradle-wrapper-validation-action
mueller-ma Sep 26, 2024
9799be2
Only replacement, no update
mueller-ma Sep 29, 2024
f1228be
Update replacements.json
mueller-ma Oct 3, 2024
0223d22
Update replacements.json
mueller-ma Oct 12, 2024
2b0581d
Merge branch 'main' into feat/rename-gradle-wrapper-validation-action
rarkins Feb 28, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions lib/data/replacements.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@
"replacements:eslint-plugin-vitest-to-scoped",
"replacements:fakerjs-to-scoped",
"replacements:fastify-to-scoped",
"replacements:gradle-wrapper-validation-action",
"replacements:hapi-to-scoped",
"replacements:jade-to-pug",
"replacements:joi-to-scoped",
Expand Down Expand Up @@ -670,6 +671,18 @@
}
]
},
"gradle-wrapper-validation-action": {
"description": "gradle/wrapper-validation-action got renamed to gradle/actions/wrapper-validation",
"packageRules": [
{
"matchCurrentVersion": "/3(\\.\\d+\\.\\d+)?/",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the intent to allow either 3 or e.g. 3.2.10? and not e.g. 3.2?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code started with:

        "matchCurrentVersion": "3",

I asked if that would match all possible versions in the 3 range:

Our developers docs list the rules for replacement presets:

Rules for replacement presets

  1. Replacement PRs should ideally propose a replacement only once the user is on a compatible version, by specifying a compatible matchCurrentVersion constraint
  2. If no compatible replacement upgrade is possible, it's acceptable to propose an incompatible one (e.g. a major version upgrade)
  3. Replacements should update the user to the first recommended version of the new dependency and not include any new changes - whether breaking or not - if they can be avoided, in short: pin the new version

If possible, replacement presets should give the user a replacement version that is functionally identical to the last version under the old name.
We only want a user's tests to fail because of broken references to the old package name, and not because the maintainer(s) changed the behavior of the package.

The key phrase in the docs is:

Replacement PRs should ideally propose a replacement only once the user is on a compatible version, by specifying a compatible matchCurrentVersion constraint

So then the question is, is just being on any version 3 of the program good enough for a user to quickly merge the replacement PR? Or does the user need to be on the last version of the old package?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So then the question is, is just being on any version 3 of the program good enough for a user to quickly merge the replacement PR? Or does the user need to be on the last version of the old package?

@HonkingGoose I think it's good replace the dependency when on any version 3.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK but should it be "matchCurrentVersion": "/^3\\.", ? Note the ^ to enforce it at the start of the line, and the mandatory . (assumes that there will always be some precision to the version and not just `"3" itself, is that safe?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The version can be v3 or v3.5.0:

So the current regex should be fine, correct?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK but should it be "matchCurrentVersion": "/^3\\.", ? Note the ^ to enforce it at the start of the line, and the mandatory . (assumes that there will always be some precision to the version and not just `"3" itself, is that safe?)

Suggested change
"matchCurrentVersion": "/3(\\.\\d+\\.\\d+)?/",
"matchCurrentVersion": "/^3\\.",

This suggestion is the copy/pasted code from @rarkins. I don't know if it's a good idea to apply the suggestion...

I'll let the maintainers decide what to do with the code. 😉

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current one allows 3, 30, 3d, etc. Is careful validation necessary to prevent these?

"matchDatasources": ["github-actions"],
"matchPackageNames": ["gradle/wrapper-validation-action"],
"replacementName": "gradle/actions/wrapper-validation",
"replacementVersion": "3.3.0"
}
]
},
"hapi-to-scoped": {
"description": "`hapi` became scoped.",
"packageRules": [
Expand Down