-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
(discussion) upgrade vs upgrade [package] version inconsistency #3603
Comments
My opinion is that we should have the following behaviors:
instead of the current:
It won't be a breaking change: we'll just be more conservative than what we're doing now, not less. |
fwiw I agree with @arcanis. |
Additional feature - Preserve version ranges:Related to #2367 and #3609 there have been requests that So for example if package.json specifies the dependency
Then if
I think this could be a bit of a can of worms though, because you can have goofy things in there:
How do you resolve these to some new "latest" and preserve the range? Alternatively, we could reuse the existing flags that
and add them to the regular |
Additional feature - Make
|
command | no arg | --latest |
---|---|---|
upgrade |
respect package.json | ignore package.json |
upgrade <name> |
respect package.json | ignore package.json |
upgrade-interactive |
respect package.json | ignore package.json |
This would make both commands consistent in behavior.
If we do this, then the --tilde
and --exact
flags should only do anything when --latest
is specified (because otherwise we aren't changing the range in package.json)
Additionally, these 2 flags would override the "preserve version range specifier" behavior mentioned above, because you have explicitly defined a new version range to use. Which means we should also add a --caret
flag.
I think that if we choose to support this, we can just support the 99% case where the reference matches |
Thanks for the This may be beyond the scope (pun not intended :), but what do you guys think about making
Proposed behavior
The benefits I see about this approach
|
Hey @kaylieEB! We really appreciate your contributions to Yarn recently. We have a #development channel on our discord server – would you like to join us there for discussions? We'd love to have you. |
Here is an interesting tidbit for discussion: Let's say you have in package.json:
and let's say you currently have left-pad Currently, if you
If you
Moving forward, what do you think we should do? My opinion is that Anyone disagree? |
That seems reasonable, yeah 👍 |
@rally25rs what would be your next step? I think all the points above make sense, would be great to get the commands consistent. |
Closing this issue. |
this is a discussion issue spawned from #3510
Existing Behavior
Currently (yarn 0.24 & 0.25) the
upgrade
command has this behavior:Given a package.json
And the
left-pad
package has these versions defined in the registry:This actually follows correctly with how the documentation for upgrade is currently written:
The current behavior happens because underneath
upgrade
it hands the parameters off to theadd
command, so it basically is the same asyarn add left-pad
.The
add
command treats the absence of an explicit version range as "uselatest
"Up For Discussion
Should we make a breaking change to
yarn upgrade [package]
and split it into the following cases:The text was updated successfully, but these errors were encountered: