[Feature] yarn workspaces foreach cannot be used to build

[alamothe]

• [X] I'd be willing to implement this feature (contributing guide)
• [X] This feature is important to have in this repository; a contrib plugin wouldn't do

Describe the user story

I have a TypeScript monorepo with multiple workspaces that depend on each other (shared libs etc.). With TypeScript, very important part is the build. Say I have a workspace A which depends on B, and workspace B which depends on C. By "depends" I mean that it is listed as a dependency with workspace:* protocol.

When I change B, I would like to make sure that it doesn't introduce compile errors in A. By looking at https://github.com/DerekZiemba/yarn-V2-workspaces-simple-monorepo I was lead to believe that yarn workspaces foreach can be used for this purpose (which the author of that repo also seems to believe).

I tried both default options and -R but it doesn't match the expectations. I execute the command inside the workspace B.

The default

~/myrepo/packages/b $ yarn workspaces foreach -vt run compile
➤ YN0000: [b]: Process started
➤ YN0000: [b]: Process exited (exit code 0), completed in 3s 962ms
➤ YN0000: Done in 3s 968ms

If executed inside a workspace, it compiles only the current workspace.

-R

~/myrepo/packages/b $ yarn workspaces foreach -vtR run compile
➤ YN0000: [b]: Process started
➤ YN0000: [b]: Process exited (exit code 0), completed in 3s 797ms

➤ YN0000: [c]: Process started
➤ YN0000: [c]: Process exited (exit code 0), completed in 4s 212ms

➤ YN0000: Done in 14s 303ms

If executed inside a workspace, it compiles the current workspace and its dependencies — which is exactly the opposite of what it needs to do when building. It should instead build B then A.

Describe the solution you'd like

Some combination of the flags to be able to produce the desired behavior for TypeScript builds.

Describe the drawbacks of your solution

This command already has a lot of flags, however they are all very confusing. This might be because I don't understand other use cases, but I do believe that build is one of the top use cases needed. Perhaps an overhaul of the flags could make the command clearer.

[seansfkelley]

I'm pretty sure you need to use --from:

yarn workspaces foreach -vtR --from b run compile

This command already has a lot of flags, however they are all very confusing.

Yeah, agreed. If you have any suggestions on how they could be redesigned I'd be curious to hear. I use it pretty frequently and still have to experiment with flag combinations sometimes.

[alamothe]

--from works, but it's very confusing that I have to specify it given that:

• I'm already in that workspace.
• It's surprising that --from reverses from dependents to dependencies. The docs do not suggest anything like that.

[unicornware]

doe anyone know if the --from option has been removed? i'm unable to use it:

Unknown Syntax Error: Unsupported option name ("--from").

$ yarn workspaces foreach [-R,--recursive] [-A,--all] [-v,--verbose] [-p,--parallel] [-i,--interlaced] [-j,--jobs #0] [-t,--topological] [--topological-dev] [--include #0] [--exclude #0] [--no-private] <commandName> ...

[mosinnik]

@unicornware check your version it looks like 2.4 output, but --from added in 3.0 version

[alamothe]

Right now we use this to build:

yarn workspaces foreach -R -ptv --from xyz run build

Thoughts:

• Why should I specify -R? That should be the default
• Why should I specify -t? That should be the default
• Why should I specify -p? That should be the default
• Why should I specify -v? That should be the default
• Instead of --from which requires the name of the workspace, it could only accept --up or --down which should be the direction from the current workspace that I am in.

[simlmx]

Glad to see there is a way to build a given workspace and the workspaces it depends on.

For the other confused people like myself:

yarn workspaces foreach --from <workspace> --recursive run build

---

Yeah, agreed. If you have any suggestions on how they could be redesigned I'd be curious to hear. I use it pretty frequently and still have to experiment with flag combinations sometimes.

@seansfkelley

Here are some ideas:

1. Remove the --topological option and always run in "topological" order. Is there any drawback to always run in "topological" order?

2. Remove the --all option and run on all workspaces if no --include is provided. The command is called foreach after all.

3. Replace --recursive and --from by something like --include-dependencies and --include-dependents (inspired from lerna) I don't really understand how --recursive works without --from to be honest!

Summary:

Run on all workspaces

yarn workspaces foreach <cmd>

Run on some workspaces

yarn workspaces foreach --include <ws1> --include <ws2> <cmd>

Run on some workspaces and their dependencies

yarn workspaces foreach --include <ws1> --include <ws2> --include-dependencies <cmd>