Do you want to request a feature or report a bug?
feature
What is the current behavior?
It is impossible (as far as I know) to specify workspaces order when running a script on all workspaces. For example, I have the core-1
and core-2
which depends on core
.
If the current behavior is a bug, please provide the steps to reproduce.
If I run yarn workspaces run build
, then it does start with core-1
, and as it depends on core
, then the build fails because the other package hasn't been built.
A temporary workaround is to use prebuild
script and then build core-1
and core-2
at build
:
...
"scripts": {
"prebuild": "yarn workspace core run build",
"build": "yarn workspace core-1 run build && yarn workspace core-2 run build"
}
...
What is the expected behavior?
To be able to somehow specify an order to run the packages.
Please mention your node.js, yarn and operating system version.
Node: 11.10.1
Yarn: 1.13.0
OS: OSX
I'm having this issue as well. You'd think it'd use the dependency graph between the packages to figure out order (like install does). Seems to be alphabetical right now.
Running scripts in dependency order by default makes the most sense to me. I assumed yarn workspace run would do this automatically but was surprised to find a build command in a package which depended on another package in the workspace used a stale version of the build.
from my testing, you _can_ specify the order. they run in whatever order you give in the packages
section of the root package.json. it looks like they only run alphabetically when evaluating wildcard patterns
@stmillMSFT Confirming that this works. It might make sense to sort wildcards in dependency order but this mitigation both easy and is more explicit.
In my opinion this is a bug.
packages/*
is default in the docsyarn workspace run
is to execute build scripts in all packagesHow do others automate this? In our environment we use mrbt, which determines the build order before launching.
Babel is using yarn in a monorepo, but not yarn workspaces…
We solved this by using wsrun: https://github.com/hfour/wsrun
@andypillip I totally agree that this is a bug. Having written dependency tree logic recently, It's really not that complex (we use it for incrementing package versions automatically), I'm surprised it's not in yarn already. It sounds like there are a ton of solutions out there for building monorepos (lerna, rush, wsrun, mrbt, etc.) in the correct order, but I really don't understand why yarn workspace run
can't do it.
from my testing, you _can_ specify the order. they run in whatever order you give in the
packages
section of the root package.json. it looks like they only run alphabetically when evaluating wildcard patterns
What is the packages
section? Do you mean the workspaces
section? I am confused because I ordered the workspaces
section accordingly and it didn't work for me.
Is there any progress on this? Yarn workspaces aren't very useful if there's no way to build the packages in the correct order.
I see it resolved in v2 (Berry)
but can we have this inside v1 too?
we expect this to work that way
That was a problem for us to use yarn to manage mono project. Do we have plan to merge the fixing to yarn v1?
@maktarsis I don't see this resolved in v2, do you have a commit sha that I could look at? I couldn't get this to work in berry but that could just be me.
Or is this implemented via workspace-tools yarn workspaces foreach -t ...
?
from my testing, you _can_ specify the order. they run in whatever order you give in the
packages
section of the root package.json. it looks like they only run alphabetically when evaluating wildcard patternsWhat is the
packages
section? Do you mean theworkspaces
section? I am confused because I ordered theworkspaces
section accordingly and it didn't work for me.
This works in Yarn 1.22.5. eg.
"workspaces": [
"packages/core",
"packages/second-one",
"packages/*"
]
Most helpful comment
from my testing, you _can_ specify the order. they run in whatever order you give in the
packages
section of the root package.json. it looks like they only run alphabetically when evaluating wildcard patterns