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.

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

Upgraded dependency exists in yarn resolutions but is different version #1792

Closed
2 of 7 tasks
ghost opened this issue Apr 4, 2018 · 4 comments
Closed
2 of 7 tasks

Comments

@ghost
Copy link

ghost commented Apr 4, 2018

This is a:

  • Bug report (non-security related)
  • Feature request
  • I'm not sure which of those it is

I'm using:

  • The Renovate GitHub App
  • Self-hosted GitHub
  • Self-hosted GitLab
  • Self-hosted VSTS

Please describe the issue:

An on-premise Renovate App instance is emitting a WARN log with the following message - Upgraded dependency exists in yarn resolutions but is different version

In the repository being renovated, the package.json file contains a resolution for a dependency.

Renovate has just filed a pull request to update that dependency, but has only updated the dependency list, and not the resolution.

Since Renovate is emitting a warning, I'm wondering what I should be doing. This does seem like maybe an issue that the repository owner will need to address. Can Renovate address it for them? Or should Renovate ask them to address it through a PR comment? Or... it this not really an actionable issue?

@rarkins
Copy link
Collaborator

rarkins commented Apr 4, 2018

What was the "before" value for that dependency in dependencies or devDependencies and what was the resolved version? Sounds like we probably should be updating the resolution too but are being too careful not to. Maybe Renovate could raise a failed status check for renovate/yarn-resolutions perhaps in cases like this.

@ghost
Copy link
Author

ghost commented Apr 4, 2018

Original value of the package:

{
  "dependencies": {
    "@scope/package": "~2.23.0"
  }
}

The change proposed by Renovate pull request:

{
  "dependencies": {
    "@scope/package": "~2.25.0"
  }
}

The resolution remains the same:

{
  "resolutions": {
     "@scope/package": "2.23.1"
  }
}

The git diff of the yarn.lock file:

-"@scope/[email protected]", "@scope/package@^2.0.0", "@scope/package@^2.15.0", "@scope/package@^2.19.0", "@scope/package@^2.21.1", "@scope/package@^2.7.1", "@scope/package@~2.23.0":
+"@scope/[email protected]", "@scope/package@^2.0.0", "@scope/package@^2.15.0", "@scope/package@^2.19.0", "@scope/package@^2.21.1", "@scope/package@^2.7.1":
   version "2.23.1"
   dependencies:
@@ -554,6 +554,16 @@
 
+"@scope/package@~2.25.0":
+  version "2.25.0"
+  dependencies:

Sorry for the obfuscation for the package name.

@rarkins
Copy link
Collaborator

rarkins commented Apr 4, 2018

what do you suggest the new resolution version should be? 2.25.0 as per the locked version?

@ghost
Copy link
Author

ghost commented Apr 5, 2018

When you specify a package like @scope/package in the resolutions field, it only overrides the version of @scope/package used by every transitive dependency. That's the existing, and intended, behavior of Yarn. (See the following issue for related commentary - yarnpkg/yarn#5505).

Therefore, the owner of the application may have intended for their application to use the latest version of @scope/package, while their transitive dependencies were to use the version specified in the resolutions field.

In that case, Renovate is working as expected.

In our particular case, however, our application intended for their application, and all their transitive dependencies, to use the same version of @scope/package. A good example of this may be when an application needs to use a specific version of Angular 1, and have all their transitive dependencies use the same version (Since Angular is a global).

In our case, our application no longer needs the resolution (they are in the process of upgrading past a patch they really needed to use), so our need for a resolution to this scenario no longer exists. I will close out the issue (We can always re-open if the use case arises again).

@ghost ghost closed this as completed Apr 5, 2018
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 2, 2021
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant