feature: workspaces: ability to install in a workspace in isolation

[bestander]

Do you want to request a feature or report a bug?
feature

What is the current behavior?

Running yarn install anywhere in a workspaced project will install node_modules in the root with hoisting and symlinking.

But sometimes one needs to test a single workspace installation in isolation from other workspaces.

Example:

I want to check if jest/packages/jest-haste-map has all dependencies listed correctly and I want to install all required node_modules inside jest/packages/jest-haste-map/node_modules.

Solution:

Introduce a new installation flag --ignore-workspaces, when you run yarn install --ignore-workspaces Yarn would not go up the folder tree and will not find the workspace root and will treet the current CWD as a single project.

Questions:

1. Should we go completely e2e here or still symlink other workspaces if they are in dependencies?

2. Should we remove node_modules from the root so that it does not affect Node.js module resolution?

[ebramanti]

@bestander This would be useful for Lerna workflows where you want to reset your workspace dependencies. I want to clean all of my monorepo dependencies except the tools installed in devDependencies in my top-level package.json. This would avoid me having to run yarn --pure-lockfile before lerna bootstrap.

[BYK]

Very similar: #4219, and possibly similar: #4207

@bestander do you think we can consolidate these three? May be in an RFC?

[bestander]

@BYK, yes this totally makes sense to have a solution that addresses all these issues.
Anyone who wants to improve Yarn feel free to send an RFC

[bdwain]

This would be really useful. I've been experimenting with workspaces recently and one of the issues I'm running into is needing to build all dependent projects just to work on a single one. The average developer in my monorepo will work in isolation on a single sub-project at a time, and the monorepo is only needed to make changes across many sub-projects all together (like a breaking change for a library). Currently, if package 1 depends on package 2, it seems like my only option is to use the local copy of package 2 in package 1, which means I have to build package 2 to work on package 1. This makes sense when I am working on both packages, but in the average case it's an extra step that can make things slow.

I can think about it some more and try to put together an RFC since that hasn't been done yet.

[bestander]

@bdwain, once you have a solution in mind send an RFC and ping me

[bdwain]

Made an RFC to address this yarnpkg/rfcs#90