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

[bdwain]

this feature was released in 1.7.0 #5663

[michaelmerrill]

@bestander Do you feel like the --focus flag solves your issue? I'm in a similar position to your original question and --focus isn't helping. I have a workspace that is a npm package. It does not depend on any other workspace package, but when I run yarn install it installs every package in the workspace. I think there is still a need for the --ignore-workspaces flag that only builds the deps in the package.json of the workspace package you are in.

[bdwain]

@michaelmerrill this sounds more like #4207. Focus definitely isn't meant to decrease installation time, and isn't really useful at all for projects that don't depend on other projects in the monorepo. It's mostly the opposite of what you want. It's meant to save on local build time, not yarn install time.

[bestander]

I have written a standalone script that reconstructs full node_modules in a given workspace that does the trick just to unblock my project.
I am not a fan of adding one more mode to install command so maybe I'll send a PR for a new isolated command if someone else needs it.

[vongohren]

I just came over this and for me the need is that I have a project that depends on 1 or two packages, but want to run it withouth the other packages, which is acctually clients. So I want to install my mobile client on its own, without having to bother all the other clients in the scope. One way we have done this is with a scripts that recreates the root package.json which removes the workspaces that we dont want to be apart of this install, and then runs yarn.

But would be nice to be able to controll this with the tool that runs the whole thing

[outdooricon]

@bestander I would love to know more!

[bestander]

@outdooricon, the script is quite simple.
It just DFS traverses package.json files starting with a workspace and copies missing packages from the root node_moduels into the workspace's node_modules.
I haven't had time to make it generic enough to share yet.

[DenyVeyten]

Will this feature may cover another use case (which is similar to @jadengore use case):
We use project root as a build environment with webpack and friends inside devDependencies of root package.json. Also, we have tens of project modules as workspaces with their own devDependencies.
During deployment, we need to use devDependencies only from the project root to build a project but have to wait for installing of all workspaces devDependencies.
Seems like with this new feature we will be able to just run
yarn --prod && yarn --ignore-workspaces
from the root and it will save a ton of time for each deployment run?

If this is not the case for this feature, I would be glad to create a separate one.

[KatieMFritz]

This would be amazing. I'm using a GitHub Actions workflow to run Cypress against our staging site after a push to the develop branch (which triggers a deployment to staging). I don't need anything but Cypress dependencies to be installed. Ignoring other workspaces would speed up the CI.

[switz]

My use-case is I have a bunch of dockerfiles in monorepos that often don't depend on each other. They have a ton of node_modules. So I'd love to be able to ignore a workspace that's expensive when building the shallower modules. That would save me ~500MB of space in my Docker images.

[theoephraim]

A very common use case to consider here is having some set of apps/sites/microservices with a set of shared utility libraries. The "apps" are totally isolated from each other, but each may depend on some subset of shared tools. For example:

- package.json (workspaces includes libs/* and apps/*)
- libs (some may depend on each other)
  - shared-lib-A
  - shared-lib-B
  - ...
- apps (each may depend on some subset of the libs)
  - api
  - frontend
  - ...

In the example above, when I'm running an install for CI/deployment/etc for that frontend app, I don't want to have to install of the api's dependencies. This could be accomplished a few different ways by passing various flags to yarn:

• only install some subset of workspaces
• install all but ignore some subset of workspaces
• focus on a single workspace, and have it automatically determine any others to include based on dependency chain

[paulshorey]

I have this problem also. Exactly as @theoephraim commented, I want to be able to deploy one of my apps at a time. When I deploy app A, I don't want it to always install all the dependencies for B and C. That wastes a lot of time waiting for things to download and install.

Makes me sad. I tried using PNPM, which does support this using the --filter flag, but unfortunately, PNPM is not good with Typescript, so after some frustration I figured it wasn't worth the effort. But for someone that really needs this to work, try PNPM, especially if you don't use Typescript much.

Also, I need one (or several) of my modules to be private, hidden from the world, as a submodule. So it's a combination of a monorepo and multirepo. A multirepo that is as easy to use as a monorepo (with Turbo/Lerna). It's actually possible (and easy) to manage some submodules in my monorepo if they are all public or if all the servers/containers that deploy the apps have the correct SSH key for all modules. But, if I don't want to share all my code, then this Yarn inability to selectively install dependencies for a particular workspace becomes a blocker! Now I have to implement ugly workarounds or abandon my architecture of a monorepo with some workspaces in submodules.

Hopefully some amazing person can contribute a fix to Yarn to allow a CLI flag to install only 1) root shared dependencies plus 2) dependencies only for the specified workspace, while keeping the Turborepo/Lerna/NX functionality of installing local sibling modules.

[stefanomiccoli]

Why do you say pnpm doesnt work well with typescript? We use pnpm in multiple monorepos that use typescript extensively without any issue.

Spare yourself the frustration of dealing with this issue that is open for 5 years no with no commitment by the maintainers and migrate from yarn to pnpm, you wont regret it also for the time saved

[stevebrowndotco]

Unless I am misunderstanding the issue, Is this not solved with hoistinglimits set to "workspace"?