-
Notifications
You must be signed in to change notification settings - Fork 2.7k
yarn upgrade should report exactly what it did #3249
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
Comments
That could be interesting. However, isn't diffing the lockfile enough? |
For projects committing the lockfile then yes, you could get the information out of that assuming you did a git commit every single time the lockfile changes. However, even then I'd argue this would be a useful summary of information to see upon running the upgrade command. But what about scenarios where the lockfile isn't being tracked (for quick test projects or playgrounds)? If the lockfile isn't tracked then you lose all previous information once an upgrade is run and thus can't do a diff. And even if you are committing the lockfile, what if you run multiple |
This is also true for global dependencies, every time you run |
I can see the point. Feel free to open a PR with a prototype! |
@bestander triage; label: [discussion | new feature] |
Do you want to request a feature or report a bug?
Feature request: yarn upgrade should report exactly what it did, so if it updated packages it should list those packages with old version and new version info, such as:
If any nested dependencies are updated those should be displayed as well (after the list of updated direct dependencies). Otherwise it should report "No packages upgraded" if nothing is changed.
It could also be useful to have an option for a log file that keeps a running log of package updates. This might be useful for diagnostics if an issue crops up in a user's codebase and there is a question about what packages might have changed during a certain time period.
What is the current behavior?
No information is reported except for the entire package tree (whether anything changed or not). I would argue that the tree output is not very useful for most people, and could be obtained through other commands if necessary.
The text was updated successfully, but these errors were encountered: