Skip to content

Fix: workspace support in several commands#4654

Merged
arcanis merged 3 commits intoyarnpkg:masterfrom
jgoz:fix-workspace-commands-2
Oct 9, 2017
Merged

Fix: workspace support in several commands#4654
arcanis merged 3 commits intoyarnpkg:masterfrom
jgoz:fix-workspace-commands-2

Conversation

@jgoz
Copy link
Copy Markdown
Contributor

@jgoz jgoz commented Oct 6, 2017

Summary

Fixes #4334
Fixes #4328
Fixes #4348

(Follow-up to #4630, #4583).

This gets several commands working when used in a workspace-enabled solution:

  • outdated:
    • when used in a workspace root or any child packages, it will show outdated packages across the entire workspace
    • added "Workspace" column to show where the outdated package is installed
  • remove:
    • when used in a workspace root, removes given package from the root only
    • when used in a workspace child, removes given package from that child only
  • upgrade:
    • when used in a workspace root, upgrades given package in root only
    • when used in a workspace child, upgrades given package in child only
  • upgrade-interactive:
    • shows outdated packages across entire workspace, and can upgrade any/all
    • added "workspace" column to show where outdated package is installed

This is slightly different from how @arcanis described in #4630, specifically with upgrade. I thought it would be less confusing/frustrating for users, especially if child workspaces have conflicting versions of the same dependency. Rather than forcing them all to the same version, this allows for fine-grained control while offering a whole-workspace upgrade option with upgrade-interactive.

Test plan

  • Added tests where appropriate
  • Existing tests pass
  • Screenshots of updated command output below:

outdated with "Workspace" column:
image

upgrade-interactive with "workspace" column:
image

jgoz added 3 commits October 6, 2017 17:08
@jgoz
Use lockfileFolder for CLI check
4300f9e
@jgoz
Make "upgrade" work inside workspace packages
d1ca59e 
Executes "fetchRequestFromCwd" in actual cwd, which ensures
"outdated" and "upgrade" commands in workspace packages
operate on the correct dependencies and preserve unrelated lockfile
entries.
@jgoz
Support workspaces in outdated and upgrade-interactive
1a86393
@buildsize
Copy link
Copy Markdown

buildsize bot commented Oct 6, 2017

This change will increase the build size from 9.91 MB to 9.92 MB, an increase of 11.57 KB (0%)

File name Previous Size New Size Change
yarn-[version].noarch.rpm 857.07 KB 857.81 KB 755 bytes (0%)
yarn-[version].js 3.77 MB 3.78 MB 4.68 KB (0%)
yarn-legacy-[version].js 3.82 MB 3.83 MB 4.66 KB (0%)
yarn-v[version].tar.gz 862.97 KB 863.63 KB 677 bytes (0%)
yarn_[version]all.deb 652.12 KB 652.94 KB 848 bytes (0%)

@BYK BYK requested a review from arcanis October 7, 2017 20:52
@JohnFultonian
Copy link
Copy Markdown

JohnFultonian commented Oct 9, 2017

Thanks for your work on this, we just started using yarn workspaces recently and this will make our lives a lot easier.

@arcanis
Copy link
Copy Markdown
Member

arcanis commented Oct 9, 2017

This is slightly different from how @arcanis described in #4630, specifically with upgrade. I thought it would be less confusing/frustrating for users, especially if child workspaces have conflicting versions of the same dependency.

Then how does it work if A and B both depend on C@~1.0.0, and you run yarn upgrade C from inside A? It will upgrade C in both A and B, right?

@jgoz
Copy link
Copy Markdown
Contributor Author

jgoz commented Oct 9, 2017 •
edited
Loading

Then how does it work if A and B both depend on C@~1.0.0, and you run yarn upgrade C from inside A? It will upgrade C in both A and B, right?

No, it will only upgrade C in A, and the lockfile will now have two entries for C. If you run yarn upgrade C in B, then they will once again converge.

This is a choice that was initially dictated by the complexity of implementing it the way you described it (where it upgrades C in both A and B when you run the command from just one workspace). There were a couple of issues to deal with here:

  • What if C is a dependency in A and a devDependency in B? We would need to change the way upgrade works to be more like upgrade-interactive, where it runs install multiple times to ensure that difference is preserved, or refactor install to accept hints about this.
  • How would a user indicate that they only want to upgrade C in A, leaving the version as ~1.0.0 in B? We would need to add a CLI flag or something to toggle this behaviour.

Then I thought about add and remove. Those only operate on a single workspace child/root, so having upgrade work this way too is arguably less confusing and more consistent. That it avoids bigger changes, refactoring in install, and extra flags is a bonus. And for upgrading C in both A and B, we can use upgrade-interactive.

arcanis
arcanis approved these changes Oct 9, 2017
View reviewed changes
Copy link
Copy Markdown
Member

@arcanis arcanis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see .. I was being confused between upgrade altering the package.json or not. Ok, yeah, it makes sense :) Let's do it this way.

@arcanis
Copy link
Copy Markdown
Member

arcanis commented Oct 9, 2017

i-ship-it-gif-16

@arcanis arcanis merged commit 7323861 into yarnpkg:master Oct 9, 2017
@jgoz jgoz deleted the fix-workspace-commands-2 branch October 9, 2017 18:40
@vvo
Copy link
Copy Markdown

vvo commented Oct 9, 2017

awesome work, thanks

This was referenced Oct 10, 2017
Open
Closed
Closed
Open
Closed
Open
@ericclemmons
Copy link
Copy Markdown

ericclemmons commented Oct 10, 2017

I just tested #4469 with v1.2.0 and it works now! 👏

@arcanis arcanis mentioned this pull request Oct 10, 2017
Merged
@milesj
Copy link
Copy Markdown

milesj commented Oct 11, 2017

@jgoz Awesome work on this PR. Such a life saver and it's been working flawlessly!

joaolucasl pushed a commit to joaolucasl/yarn that referenced this pull request Oct 27, 2017
@jgoz @joaolucasl
Fix: workspace support in several commands (yarnpkg#4654)
6b5a518 
* Use lockfileFolder for CLI check

* Make "upgrade" work inside workspace packages

Executes "fetchRequestFromCwd" in actual cwd, which ensures
"outdated" and "upgrade" commands in workspace packages
operate on the correct dependencies and preserve unrelated lockfile
entries.

* Support workspaces in outdated and upgrade-interactive
@arcanis arcanis mentioned this pull request Sep 18, 2019
Open
@nwittwer nwittwer mentioned this pull request Jul 14, 2021
Open
2 tasks
@kachkaev kachkaev mentioned this pull request Jan 24, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@arcanis arcanis arcanis approved these changes

Assignees

@arcanis arcanis

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@jgoz @JohnFultonian @arcanis @vvo @ericclemmons @milesj