Describe the user story
In a large Yarn monorepo using nodeLinker: node-modules with [N] workspaces, I regularly run tests from workspaces outside my main area of work.
Running yarn workspaces focus <workspace> removes packages from node_modules that are not needed by that workspace. On our repository, focusing takes a few minutes, and returning to my normal workspace setup takes a few more. I repeat this workflow a few times, so the unlink/relink cycle can add up and be pretty painful.
I am not sure if this issue affects repos using PnP, as I haven't had a chance to work in a large monorepo that uses it.
Describe the solution you'd like
Ideally I want a way to only ensure that all the dependencies for a workspace are present, without doing any pruning or unlinking of extraneous node modules. I'd propose adding a --keep-existing flag (defaults to off, so no behavior change unless the flag is passed) to the yarn workspaces focus command but open to other APIs.
Describe the drawbacks of your solution
The main drawback I can see is that it may leave stale dependencies laying around, since it likely means we also wouldn't cleanup stale modules after they've been removed from package.json. To my mind this is pretty minor, since these stale dependencies mostly shouldn't hurt anybody, and it's pretty easy to get back to a clean state by just not passing the new flag, though I could see it causing issues to be created here if people get themselves into a bad state by abusing the flag.
Describe alternatives you've considered
Why not make it a plugin: My understanding is that since this requires changing install behavior, not adding to it, a plugin wouldn't be able to accomplish what I'm asking without significantly duplicating the logic that exists here.
Other solutions I've considered:
Maintaining state of which workspaces are currently "focused" and using that to allow for more custom plugin based workflows. This seems much more complex to me, as you'd need to figure out where to store that state, and how to keep it up to date as external factors change the yarn install state and edit package.json, and still only provides a partial solution because it would require a plugin built on top of it to actually improve the real behavior.
Describe the user story
In a large Yarn monorepo using
nodeLinker: node-moduleswith [N] workspaces, I regularly run tests from workspaces outside my main area of work.Running
yarn workspaces focus <workspace>removes packages fromnode_modulesthat are not needed by that workspace. On our repository, focusing takes a few minutes, and returning to my normal workspace setup takes a few more. I repeat this workflow a few times, so the unlink/relink cycle can add up and be pretty painful.I am not sure if this issue affects repos using PnP, as I haven't had a chance to work in a large monorepo that uses it.
Describe the solution you'd like
Ideally I want a way to only ensure that all the dependencies for a workspace are present, without doing any pruning or unlinking of extraneous node modules. I'd propose adding a
--keep-existingflag (defaults to off, so no behavior change unless the flag is passed) to theyarn workspaces focuscommand but open to other APIs.Describe the drawbacks of your solution
The main drawback I can see is that it may leave stale dependencies laying around, since it likely means we also wouldn't cleanup stale modules after they've been removed from package.json. To my mind this is pretty minor, since these stale dependencies mostly shouldn't hurt anybody, and it's pretty easy to get back to a clean state by just not passing the new flag, though I could see it causing issues to be created here if people get themselves into a bad state by abusing the flag.
Describe alternatives you've considered
Why not make it a plugin: My understanding is that since this requires changing install behavior, not adding to it, a plugin wouldn't be able to accomplish what I'm asking without significantly duplicating the logic that exists here.
Other solutions I've considered:
Maintaining state of which workspaces are currently "focused" and using that to allow for more custom plugin based workflows. This seems much more complex to me, as you'd need to figure out where to store that state, and how to keep it up to date as external factors change the yarn install state and edit package.json, and still only provides a partial solution because it would require a plugin built on top of it to actually improve the real behavior.