“Sparse” workspaces

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.

Author: Fantashit

4 thoughts on ““Sparse” workspaces

  1. 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.

  2. 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.

Comments are closed.