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

Jump to bottom

[Feature] upgrade-interactive feature to show workspaces #2591

Open
1 of 2 tasks
Yzrsah opened this issue Mar 10, 2021 · 6 comments · May be fixed by #3260
Open
1 of 2 tasks

[Feature] upgrade-interactive feature to show workspaces #2591

Yzrsah opened this issue Mar 10, 2021 · 6 comments · May be fixed by #3260
Labels
enhancement New feature or request

Comments

@Yzrsah
Copy link

Yzrsah commented Mar 10, 2021 •
edited
Loading

  • I'd be willing to implement this feature (contributing guide)
  • This feature is important to have in this repository; a contrib plugin wouldn't do

Describe the user story

Yarn upgrade-interactive is a great time-saver!

I have workspaces that use different versions of the same package. For example, one workspace is using a version ^4.11.3 and another workspace is using version next.

The problem is that when I run yarn upgrade-interactive, there is no information about which workspaces are being upgraded, and the information that is displayed is not accurate:

? Pick the packages you want to upgrade.          Current          Range            Latest

 > @material-ui/core                             ◉ next           ◯ ^5.0.0-alpha.… ◯ ^4.11.3       
   @material-ui/icons                            ◉ next           ◯ ^5.0.0-alpha.… ◯ ^4.11.2

This is not accurate because the menu only shows the Current version as next, despite the fact that there's multiple workspaces, some using next and some using ^4.11.3.

Which workspaces is it going to upgrade if I change the version?

How can the user understand what will be upgraded?

Describe the solution you'd like

A few possible solutions for this:

  1. A workspace column
  • The workspace column would only appear when the package has workspaces.
  • The workspace column would only appear when multiple workspaces use different versions of a package.
  • Optionally yarn upgrade-interactive --workspace-versions would always show the workspace column and always show separate entries for each workspace, not just when there's multiple versions.
? Pick the packages to upgrade.    Workspace          Current          Range            Latest

 > @material-ui/core               foo                ◉ next           ◯ ^5.0.0-alpha.… ◯ ^4.11.3
   @material-ui/core               bar                ◉ ^4.11.2        ◯ ^4.11.3
  1. A separate section for each workspace (more rows)
  • This would display a separate group for each workspace
  • By default, the workspace section would only appear when multiple workspaces use different versions of a package.
  • Optionally yarn upgrade-interactive --workspace-versions would always show a separate section for each workspace.
? Pick the packages you want to upgrade.          Current          Range            Latest

Workspace: foo
 > @material-ui/core                             ◉ next           ◯ ^5.0.0-alpha.… ◯ ^4.11.3    

Workspace: bar
   @material-ui/core                             ◉ ^4.11.2        ◯ ^4.11.3

Describe the drawbacks of your solution

If someone was upgrading a messy package with a bunch of workspaces that had different versions of things, they may have to press enter more times.

Describe alternatives you've considered

Since it's ambiguous about which workspaces will be upgraded (Current does not reflect the version used by some workspaces), this could be considered a bug.
@Yzrsah Yzrsah added the enhancement New feature or request label Mar 10, 2021
@schickling
Copy link

Was just about to open an issue suggesting the same feature. Glad to see someone has already requested this. I especially like this part:

image

@nwittwer
Copy link

nwittwer commented Jul 14, 2021 •
edited
Loading

Hoping to see this as well in Yarn v2. Came across a feature for Yarn ~v1.2 that implemented something similar: yarnpkg/yarn#4654 (comment)

Ideally this feature could also filter the results to just one workspace, too. For example, cd to a workspace directory or run yarn workspace myworkspace upgrade-interactive and the list of possible upgrades would be limited to that workspace.

@semanser semanser linked a pull request Aug 9, 2021 that will close this issue
Open
3 tasks
@merceyz merceyz mentioned this issue Aug 12, 2021
Closed
2 tasks
@eliw00d
Copy link

eliw00d commented Mar 31, 2022 •
edited
Loading

I would love to see:

yarn workspace my-workspace upgrade-interactive

or

cd my-workspace && yarn upgrade-interactive # only shows upgrades for current workspace

and/or show which workspaces have dependencies when selecting versions.

Currently, we have to refer to package.json files to see which versions are in which workspaces. Quite the chore in a large monorepo!

@stefanomiccoli
Copy link

agree! and it gets especially confusing when multiple packages have the same dependency version, but you only want to update one...

it worked perfectly fine with yarn1, i dont get how a regression like this could be left unresolved for years

@bryanph
Copy link

bryanph commented Apr 1, 2022

There's a PR open for this here #3260

@eyolas
Copy link

eyolas commented Jun 13, 2022

I have created a plugin for yarn : https://github.com/eyolas/yarn-plugin-interractive-filter
It's a fork of upgrade-interactive that take a list of workspace to filter

@arcanis arcanis mentioned this issue Feb 6, 2023
Open
2 tasks
petermetz added a commit to petermetz/cacti that referenced this issue Jun 1, 2024
@petermetz
build(yarn): add plugin-interactive-filter to manage deps per-package
6550907 
This plugin allows to resolve some CVEs more surgically that are found in indirect
dependencies which are difficult to upgrade without triggering a large change
needed and potential migrations, breaking changes to the public APIs of packages.

The reason why the above problem happens is because `yarn up` and `yarn up -R`
are blunt instruments when it comes to managing a monorepo such as ours:
They do their upgrade all-or-nothing, e.g. you can't upgrade a single dependency
in a single monorepo package, you must upgrade the dependency project-wide
with the mentioned tools, but sometimes we need to perform the upgrade just in a
single monorepo package.

For example to the above, about 20 packages use web3 but only about 5 of those
are using v4.x versions of web3. A new CVE came out covering v4.1.x and so
I needed to upgrade web3 only in those packages where web3 was already above
v4.0.0 and leave the older ones alone (surgical upgrades).

To accomplish this I've found no way to do it with stock yarn CLI commands, but
someone who had the exact same problem had written a plugin for solving it.

The original issue reported to yarn with the same problem we are having:
yarnpkg/berry#2591

The repository where the plugin resides that we are adding in this commit in
order to remediate the problem of lack of surgical (per-package) upgrades:
https://github.com/eyolas/yarn-plugin-interractive-filter

The original CVE that I was investigating as I stumbled upon the solution:
- https://github.com/hyperledger/cacti/pull/3264
- https://github.com/hyperledger/cacti/security/dependabot/987

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
@petermetz petermetz mentioned this issue Jun 1, 2024
Merged
5 tasks
petermetz added a commit to petermetz/cacti that referenced this issue Jun 6, 2024
@petermetz
build(yarn): add plugin-interactive-filter to manage deps per-package
7249313 
This plugin allows to resolve some CVEs more surgically that are found in indirect
dependencies which are difficult to upgrade without triggering a large change
needed and potential migrations, breaking changes to the public APIs of packages.

The reason why the above problem happens is because `yarn up` and `yarn up -R`
are blunt instruments when it comes to managing a monorepo such as ours:
They do their upgrade all-or-nothing, e.g. you can't upgrade a single dependency
in a single monorepo package, you must upgrade the dependency project-wide
with the mentioned tools, but sometimes we need to perform the upgrade just in a
single monorepo package.

For example to the above, about 20 packages use web3 but only about 5 of those
are using v4.x versions of web3. A new CVE came out covering v4.1.x and so
I needed to upgrade web3 only in those packages where web3 was already above
v4.0.0 and leave the older ones alone (surgical upgrades).

To accomplish this I've found no way to do it with stock yarn CLI commands, but
someone who had the exact same problem had written a plugin for solving it.

The original issue reported to yarn with the same problem we are having:
yarnpkg/berry#2591

The repository where the plugin resides that we are adding in this commit in
order to remediate the problem of lack of surgical (per-package) upgrades:
https://github.com/eyolas/yarn-plugin-interractive-filter

The original CVE that I was investigating as I stumbled upon the solution:
- https://github.com/hyperledger/cacti/pull/3264
- https://github.com/hyperledger/cacti/security/dependabot/987

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to hyperledger-cacti/cacti that referenced this issue Jun 6, 2024
@petermetz
build(yarn): add plugin-interactive-filter to manage deps per-package
13f457c 
This plugin allows to resolve some CVEs more surgically that are found in indirect
dependencies which are difficult to upgrade without triggering a large change
needed and potential migrations, breaking changes to the public APIs of packages.

The reason why the above problem happens is because `yarn up` and `yarn up -R`
are blunt instruments when it comes to managing a monorepo such as ours:
They do their upgrade all-or-nothing, e.g. you can't upgrade a single dependency
in a single monorepo package, you must upgrade the dependency project-wide
with the mentioned tools, but sometimes we need to perform the upgrade just in a
single monorepo package.

For example to the above, about 20 packages use web3 but only about 5 of those
are using v4.x versions of web3. A new CVE came out covering v4.1.x and so
I needed to upgrade web3 only in those packages where web3 was already above
v4.0.0 and leave the older ones alone (surgical upgrades).

To accomplish this I've found no way to do it with stock yarn CLI commands, but
someone who had the exact same problem had written a plugin for solving it.

The original issue reported to yarn with the same problem we are having:
yarnpkg/berry#2591

The repository where the plugin resides that we are adding in this commit in
order to remediate the problem of lack of surgical (per-package) upgrades:
https://github.com/eyolas/yarn-plugin-interractive-filter

The original CVE that I was investigating as I stumbled upon the solution:
- https://github.com/hyperledger/cacti/pull/3264
- https://github.com/hyperledger/cacti/security/dependabot/987

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
fazzatti pushed a commit to fazzatti/cacti that referenced this issue Jun 24, 2024
@petermetz @fazzatti
build(yarn): add plugin-interactive-filter to manage deps per-package
4b65daa 
This plugin allows to resolve some CVEs more surgically that are found in indirect
dependencies which are difficult to upgrade without triggering a large change
needed and potential migrations, breaking changes to the public APIs of packages.

The reason why the above problem happens is because `yarn up` and `yarn up -R`
are blunt instruments when it comes to managing a monorepo such as ours:
They do their upgrade all-or-nothing, e.g. you can't upgrade a single dependency
in a single monorepo package, you must upgrade the dependency project-wide
with the mentioned tools, but sometimes we need to perform the upgrade just in a
single monorepo package.

For example to the above, about 20 packages use web3 but only about 5 of those
are using v4.x versions of web3. A new CVE came out covering v4.1.x and so
I needed to upgrade web3 only in those packages where web3 was already above
v4.0.0 and leave the older ones alone (surgical upgrades).

To accomplish this I've found no way to do it with stock yarn CLI commands, but
someone who had the exact same problem had written a plugin for solving it.

The original issue reported to yarn with the same problem we are having:
yarnpkg/berry#2591

The repository where the plugin resides that we are adding in this commit in
order to remediate the problem of lack of surgical (per-package) upgrades:
https://github.com/eyolas/yarn-plugin-interractive-filter

The original CVE that I was investigating as I stumbled upon the solution:
- https://github.com/hyperledger/cacti/pull/3264
- https://github.com/hyperledger/cacti/security/dependabot/987

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
sandeepnRES pushed a commit to sandeepnRES/cacti that referenced this issue Jul 30, 2024
@petermetz @sandeepnRES
build(yarn): add plugin-interactive-filter to manage deps per-package
e2f688f 
This plugin allows to resolve some CVEs more surgically that are found in indirect
dependencies which are difficult to upgrade without triggering a large change
needed and potential migrations, breaking changes to the public APIs of packages.

The reason why the above problem happens is because `yarn up` and `yarn up -R`
are blunt instruments when it comes to managing a monorepo such as ours:
They do their upgrade all-or-nothing, e.g. you can't upgrade a single dependency
in a single monorepo package, you must upgrade the dependency project-wide
with the mentioned tools, but sometimes we need to perform the upgrade just in a
single monorepo package.

For example to the above, about 20 packages use web3 but only about 5 of those
are using v4.x versions of web3. A new CVE came out covering v4.1.x and so
I needed to upgrade web3 only in those packages where web3 was already above
v4.0.0 and leave the older ones alone (surgical upgrades).

To accomplish this I've found no way to do it with stock yarn CLI commands, but
someone who had the exact same problem had written a plugin for solving it.

The original issue reported to yarn with the same problem we are having:
yarnpkg/berry#2591

The repository where the plugin resides that we are adding in this commit in
order to remediate the problem of lack of surgical (per-package) upgrades:
https://github.com/eyolas/yarn-plugin-interractive-filter

The original CVE that I was investigating as I stumbled upon the solution:
- https://github.com/hyperledger/cacti/pull/3264
- https://github.com/hyperledger/cacti/security/dependabot/987

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(interactive-tools): show workspaces info in upgrade-interactive semanser/berry
7 participants
@stefanomiccoli @eyolas @schickling @eliw00d @bryanph @nwittwer @Yzrsah