Open alamothe opened 2 years ago
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.
--from
works, but it's very confusing that I have to specify it given that:
--from
reverses from dependents to dependencies. The docs do not suggest anything like that.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> ...
@unicornware check your version it looks like 2.4 output, but --from added in 3.0 version
Right now we use this to build:
yarn workspaces foreach -R -ptv --from xyz run build
Thoughts:
-R
? That should be the default-t
? That should be the default-p
? That should be the default-v
? That should be the default--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.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
Remove the --topological
option and always run in "topological" order.
Is there any drawback to always run in "topological" order?
Remove the --all
option and run on all workspaces if no --include
is provided.
The command is called foreach
after all.
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!
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>
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
If executed inside a workspace, it compiles only the current workspace.
-R
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.