Yarn: "Sparse" workspaces

[arcanis]

Running yarn install inside a workspace installs the dependency for all the workspaces (because we effectively go to the root of the workspace and run yarn install from there). This should be improved in such a way that running yarn install inside a workspace will only install this workspace's dependencies (plus those required by any other workspace that we depend on).

Subtlety: we should be careful and preserve the file hierarchy, even if it's a partial install (ie. we should apply the hoisting process before cutting unneeded dependencies from the tree). Otherwise, we might have disparities in which modules are required when doing sparse installs vs full installs.

[BYK]

Similar #4219 (definitely not the same)

[cappslock]

Just got bit by this, which unfortunately is requiring me to use Lerna instead. So yeah, +1.

[tamlyn]

Is this just a performance optimisation when working with large workspaces? I don't think the current default behavior should change as being able to run yarn from anywhere in the project is one of the nice improvements over lerna.

[cappslock]

As far as I can tell that's the main/only use case. I like the default behavior, but being able to opt in to scoping installs to a workspace and its dependencies would be very helpful for this sort of use case.

[RyanMcDonald]

I also just ran into this. I have been using yarn workspaces to manage a repository of lambda functions. Workspaces allow me to share code between the lambda functions, so the shared code gets bundled as a dependency before uploading to AWS.

In my case, I was using --modules-folder to have a fresh install of one function's dependencies, but that folder ended up including all dependencies from every workspace because of this issue. 😞

[bdwain]

~I think this use case could be addressed by https://github.com/yarnpkg/rfcs/pull/90~

EDIT: that proposal changed a bit and now doesn't really address this anymore.

[denkristoffer]

This could bring big improvements to CI runs for our monorepo, so it would be a welcome addition 👍

[arcanis]

I believe sparse checkouts are a false solution. What I believe matter are fast install times and increased stability - the way it's implemented doesn't matter per se.

The way I'm working on that is through zero-installs which will come starting from the v2.

[cappslock]

@arcanis I think you're correct for many cases, but keep in mind that total bundle size can be relevant.

[robchristian]

This is definitely needed. If we have a repo where the dependencies in ProjectA are failing to install correctly for certain team members (perhaps env build issues – looking at you node-gyp), those members will be blocked even if they aren't working on ProjectA. Being able to install only the dependencies for ProjectB and not ProjectA would likely unblock them (assuming ProjectB doesn't share the same failing dependencies).

Aside from that, it also just saves people a lot of time if ProjectA dependencies take much more time to install than ProjectB.