[rush] Feature Request - rush `upgrade-interactive`

[TheLarkInn]

Summary

Updating packages in large scale projects today involves having to fuss with package.json files, reference approved versions, and manually making entries and running rush update. This can be quite cumbersome, and this high barrier to management seems to create atrophy in staying up to date with dependencies across a monorepository.

We can lower this barrier to management by leveraging prior work from tools like yarn upgrade-interactive and npm-check to provide visual terminal prompts helping users manage their project dependencies.

npm-check has a UI like this:

yarn upgrade-interactive looks like this:

Design Outline

rush upgrade-interactive

• [x] List all project packages
  • [x] User selects one (or many?) packages
• [x] update-interactive --all prompt
• [x] npm-check style prompt performed on that package.json for that project
  • [x] Prompt for changes provided
• [x] Tool updates the package.json file for that project
  • [x] Rush check (?)
  • [x] Prompt/Tool for updating approved/optional versions json file
• [ ] Prompt for additional projects to update packages
  • [ ] If yes, repeat steps
  • [ ] If no, rush update

[TheLarkInn]

I have not reviewed the API surface for @dylang 's npm-check but I very much like the UI and it would be great to reuse a lot of its capabilities instead of rewriting our own visualizer, picker, prompter, etc. I will research this.

[iclanton]

The would make a great plugin.

[TheLarkInn]

I've been able to generate a prompt for packages and updating, but I'd like some design discussion around how we go about updates.

Questions to discuss:

• When a package is chosen to be upgraded on one package how should we upgrade the dependency: update the dep across all packages or just the one package? (I'm leaning towards all packages with an optional flag for one package)
• If we update a dependency on just one package, do we automatically resolve "optional/approved versions" or prompt to automatically resolve it?

[h-parker-higgins]

I've been doing an analysis of rushstack from a developer experience perspective and this this is the missing feature we were looking for. An easy way to update outdated packages and address vulnerabilities across an entire monorepo. Would be great to see it treated as a first class citizen in rush. My vote would also be "I'm leaning towards all packages with an optional flag for one package" @TheLarkInn @iclanton

[h-parker-higgins]

Cross sharing here: there definitely sounds like there's some demand coming from the Renovate community: https://github.com/renovatebot/renovate/discussions/13818

[TheLarkInn]

@h-parker-higgins this sounds reasonable enough. Some repositories have hundreds of packages and thousands of dependencies, so scale has to also be taken into consideration. When I draft the design review for this I'll try to cover both scenarios.

[TheLarkInn]

Remaining Work:

• [ ] Inquirer project filtering
• [ ] upgrade-interactive --only flag support
  • [ ] rush.json project name
  • [ ] npm package.json name
• [ ] upgrade-interactive --all flag support
• [ ] code complete quality
• [ ] typescript warnings
• [ ] lib refactoring (do we rewrite npm-check and use our own)
• [ ] registry check optimization
• [ ] helpful console output about updating other packages

[yume-chan]

Before rush upgrade-interactive --all is implemented, I found that if the monorepo is using pnpm workspace, I can run pnpm recursive upgrade --interactive --latest in common/temp folder, followed by rush update to upgrade dependencies of all packages.

It also alphabetically sorts dependency list in package.json, refs #2496

[elliot-nelson]

A minor usability nit: I watched someone relatively new to Rush run upgrade-interactive yesterday, and on an older Mac in our monorepo, it took ~15 seconds to load up the CLI interface (they started pressing random keys about 2 seconds in 😆).

Some kind of progress bar while it scrapes together package info would definitely help.

[Faithfinder]

I posted my feedback on Zulip before, but it was in a somewhat random thread, so, duplicating here, in no particular order:

• Infinite scroll is slightly confusing
• I want an -all mode to choose packages to upgrade across the repo (not sure if it's the same as all from "Remaining work" above)
• For some packages, you need to be able to select a version to upgrade to. @types/node is a good example - I want latest 16, but not ready to upgrade to 18 yet. Or sometimes I might want to upgrade to a beta.
• I'd also look into downgrading scenario