Currently, exit code 1 is returned if option --fast-exit is set and the execution is ended prematurely due to the script returning an exit code > 0 for any of the workspaces.

However, if option --fast-exit is not set, wsrun always returns exit code 0.

From my perspective, this should be changed to always return exit code 1 if any of the scripts failed, independent of whether or not --fast-exit is set.

This behavior would be more consistent, especially considering that the current behavior is not documented for --fast-exit. It would also be beneficial in scenarios where wsrun should be chained with other commands and the exit code is used to decide on whether or not to continue execution.

Especially in combination with #15, this should be fairly trivial to implement, as we have all the necessary information available already.

How do you feel about this?

Thank you for this package. I want to use it as an alternative to Lerna. In Lerna "run " only executes the command if it is available in package.json:scripts[<cmd>]. Can the same feature be added to this lib?

E.g. say I have 10 packages in my workspace, but only 8 have a build command in the scripts section of the package.json. I'd like to just call $ yarn wsrun build --stages without the need to use --exclude for the other 2 packages.

I'd appreciate a way to run an arbitrary shell command via wsrun, for example:

wsrun -p @my/package --raw "ls -la"

Hopefully I didn't miss a way to do this currently, neither of these worked for me:

wsrun -p @my/package --bin "ls -la"
wsrun -p @my/package --bin ls -c "-la"

(The second is weird anyway.)

It'd be useful to have an option to arbitrarily limit the amount of running scripts to a certain maximum, such as 5 or 10.

For the most part, I've been able to rely on --stages to prevent too much from happening at once, but with the introduction of one new package that has no inter-workspace dependencies, it has become too much for the CI server I'm using to handle.

We use wsrun in our monorepo to run the typescript compiler in watch mode.
While setting up the vscode default build task and the problem matcher, I've tried to let wsrun rewrite tsc output paths. That fails currently.

package
 | src/index.tsx(33,5): error TS2304: Cannot find name 'adsf'.

Would it be an option to give wsrun a pattern which should be checked?

Thanks for this tool, it is nice to have something lightweight to just run commands!

Now, when I tried it it worked but I got some issues with the output. This is what I am seeing:

$ yarn build2
yarn run v1.3.2
$ wsrun build --stages
>>> @promaster/edit-plugin-adapter $ yarn build
>>> @promaster/edit-plugin-core $ yarn build
>>> @promaster/example-plugin $ yarn build
$ tsc -p tsconfig-build.json
$ tsc -p tsconfig-build.json
$ tsc -p tsconfig-build.json
@promaster/exa  |
@promaster/exa  |
@promaster/edi  |
@promaster/edi  |
@promaster/edi  |
@promaster/edi  |
>>> @promaster/plugin-test-runner $ yarn build
$ tsc -p tsconfig-build.json
@promaster/plu  |
@promaster/plu  |
Done in 8.96s.

So basically it is running the build cmd for 4 packages. My issues are these:

1. Since I have an organization prefix, the output prefix for each package is too short identity which package the output is for
2. There are blank lines outputted that are not there if I run the same cmd in each repo without wsrun.

$ yarn  wsrun --version
yarn run v1.13.0
$ node_modules/.bin/wsrun --version
3.6.4

For some reason wsrun is unable to run a specific package, but doesn't tell me what the problem is:

$ yarn yarn-wsrun -p @foo/mypackage lint
yarn run v1.13.0
$ wsrun --concurrency=2 --report --exclude-missing -p @foo/mypackage lint
wsrun [options] <command> [<arg1> <arg2> ...]

Mode (choose one):
  --parallel  Fully parallel mode (default)                                                                                                                                       [boolean]
  --stages    Run in stages: start with packages that have no deps                                                                                                                [boolean]
  --serial    Same as "stages" but with no parallelism at the stage level                                                                                                         [boolean]

Package Options:
  --recursive, -r  Execute the same script on all of its dependencies, too                                                                                                        [boolean]
  --package, -p    Run only for packages matching this glob. Can be used multiple times.                                                                                            [array]

Misc Options:
  --fast-exit        If at least one script exits with code > 0, abort                                                                                                            [boolean]
  --collect-logs     Collect per-package output and print it at the end of each script                                                                                            [boolean]
  --no-prefix        Don't prefix output                                                                                                                                          [boolean]
  --bin              The program to pass the command to                                                                                                          [string] [default: "yarn"]
  --done-criteria    Consider a process "done" when an output line matches the specified RegExp
  --exclude          Skip running the command for that package                                                                                                                     [string]
  --exclude-missing  Skip packages which lack the specified command in the scripts section of their package.json                                                                  [boolean]
  --report           Show an execution report once the command has finished in each package                                                                                       [boolean]
  --if               Run main command only if this condition runs successfully
  --ifDependency     Run main command only if packages dependencies passed the condition (not available in parallel mode)                                                         [boolean]

Other Options:
  --help         Show help                                                                                                                                                        [boolean]
  --version      Show version number                                                                                                                                              [boolean]
  -c             Denotes the end of the package list and the beginning of the command. Can be used instead of "--"                                                                [boolean]
  --concurrency  Maximum number of commands to be executed at once                                                                                                                 [number]

Examples:
  wsrun clean                                      Runs "yarn clean" in each of the packages in parallel
  wsrun -p app -r --stages build                   Runs "yarn build" in app and all of its dependencies in stages, moving up the dependency tree
  wsrun --stages --done-criteria="Finished" watch  Runs "yarn watch" in each of the packages in stages, continuing when the process outputs "Finished"
  wsrun --exclude-missing test                     Runs "yarn test" in all packages that have such a script

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

The package does exist though:

$ yarn workspaces info
yarn workspaces v1.13.0
{
  "@foo/mypackage": {
    "location": "src/libs/mypackage",
    "workspaceDependencies": [],
    "mismatchedWorkspaceDependencies": []
  }
}
✨  Done in 0.12s.

What am I doing wrong here? I was hoping wsrun to tell me what's missing.

After upgrading to 4.0.0, wsrun is no longer working.
I am using yarn workspaces, with wsrun installed at the root level.

'wsrun' is not recognized as an internal or external command,
operable program or batch file.

If I downgrade to 3.6.6, everything runs perfectly.

Hey, could you please release the latest changes in master to support the new configurations syntax of workspaces in package.json to npm? I am working on a project that needs nohoist and would like to use wsrun.

Say you run a watch script with wsrun in a workspace-based project with three packages and all three packages need to listen to a unique port. You could use some "find open port"-lib for this, but because of data races this can become quite flaky in my experiences, when watch is called parallel. It would probably be less error prone, if we could access an environment variable like WSRUN_INDEX which has the values 0, 1 and 2 to indicate that the script was called nth-times by wsrun in this case and we could use this value to define a port in the watch script like this: const port = 8080 + parseInt(WSRUN_INDEX|| 0, 10).

(Note: I added the same request to yarns workspace run proposal. yarnpkg/rfcs#87 (comment))

I don´t know if that is intended but having @babel/core as a devDependency throws this:

ERROR: Dependency cycle detected:
   @babel/core <- debug <- @babel/core

wsrun is going to far on this because debug's devDependency shouldn't be considered in the cycle detection, should it?

What should I do?

When I call yarn wsrun from the workspace root, everything executes as expected. But when I navigate within a workspace and attempt to call yarn wsrun, it seems to exit immediately without having any effect. I've tried adding wsrun as a devDependency to both the root and the workspace directly, but neither seems to work.

The scenario is that I'd like to add a script to a package that allows me to call e.g. yarn build-dependencies from within the package and have all its dependencies automatically built.

Please provide option to disable cycle detection.

I'm using yarn workspaces in two projects written in typescript where they reference each other.
It works okay if I use ts-node to:

• first make an in-memory compilation of the code
• and only afterwards build a JS libraries using rollup
  It doesn't produce a dead loop, but wsrun throws an error even why I don't specify --recursive option.

Could be done by wrapping this block with new option, like --no-cycle-detection

Please let me know if you want me to do a PR.

Jest outputs things in colour using ANSI shell escape codes. wsrun seems to choke on these when rewriting paths.

$ wsrun --exclude-missing --serial test
some-workspace
yarn run v1.15.2
$ jest
 |  PASS  ackages/ui/2mtest/components/Component.test.tsx
 |   ✓ does a thing (1ms)
 |   ✓ does another thing (2ms)
 |   ✓ does a third thing (3ms)
 |
 | Test Suites: 1 passed, 1 total
 | Tests:       3 passed, 3 total
 | Snapshots:   0 total
 | Time:        10ms
 | Ran all test suites.
Done in 1s.

Instead of:

 |  PASS  ackages/ui/2mtest/components/Component.test.tsx

I expect:

 |  PASS  packages/ui/test/components/Component.test.tsx

--no-prefix doesn't work for me because I'd like to know which workspace each test block is running in.

A useful workaround would be to tell wsrun not to modify paths, but I can't find a switch for that.

Hi,

First, thank you for this awesome package!! You saved me hours of setup!

It would be nice if yarn wsrun --stages build only builds packages that has changed since last command call.

Building all the packages takes 2 mns in my case, but often, I only change one small package and I have to rebuild everything.

Thank you,
Lucas Willems

Not sure if this is expected behavior or not.

if you run yarn wsrun --if ... and the condition script failed, error messages like these are in the output:

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

but these are not useful information, it is expected for the command to fail when the if condition does not met.

In the code, wsrun always set silent option to true if the command is used for the --if argument, but the code is not checking silent flag before output to console, I have to add if (!this.opts.silent) on line

In this case, should wsrun write anything to console if silent is set to true? If yes, can we add a command line option to mute all output for the commands used as if conditions?

I have a repo with a top-level package.json that looks similar to this:

{
  "name": "my-repo",
  "private": true,
  "workspaces": {
    "packages": [
      "backend/*",
      "common/*",
      "frontend/*"
    ]
  }
}

In 3.5.0, wsrun clean would appropriately execute on all workspaces within backend, common, and frontend.

In 3.6.1, wsrun clean does not execute a single command.

I suspect the issue is with a3503be, as the globs default to ['*'] when it should instead probably default to whatever workspaces within the top-level package.json specifies.

Would be useful to run commands on items that have changed (in git) since a certain tag or branch, similar to how Jest does it.

Hey,

Thanks for this tool! it helps us manage our yarn workspace.

However, there are some things we want to customize, that require running code on all packages.
A good example is synching a config file across all packages.

WDYS about exposing some kind of API? for example, allow iteration on all packages folders.

I love this tool, but I think it would become even better if there was an option to set up a .wsrunrc config file. As per the latest v3 breaking chances, scripts looks rather verbose now:

wsrun --exclude-missing --fast-exit --package $PKG --recursive --stages build

Many of my scripts share the same options, such as --exclude-missing or --fast-exit. It would be nice to set them only once.

I'm trying a basic example of

yarn wsrun -p @my/package test

and it just prints help and exists with an exit code 1.

I also tried:

• Add quotes: yarn wsrun -p "@my/package" test
• Use folder name instead of name in package.json: yarn wsrun -p my-package test

We have a yarn monorepo and run the build step as follows:

"build": "wsrun --stages --fast-exit --collect-logs --report build:packagr ",

If one one the modules fails we see in a report what module failed but not why, the error output of the failing module is lost. All we see is:

1 packages finished `build:packagr` with error: @prod-publishing-react/block-settings

If we then just run the build command for the failing package again via yarn, e.g. like:

yarn workspace @prod-publishing-react/block-settings build:packagr

we see the reason for the failure on stderr.

Question: how can we make sure to see the stderr of a failing module when using wsrun?

In the log when starting to watch the applications I get this message for several packages:
has no build:rest script, skipping missing

Can we change this to a more clear message, maybe change it to:
skipping packages with missing scripts

wsrun -s pre-commit results in a cmd is undefined error. The only way I'm able to pass the -s flag (silent mode) to yarn is with --bin="yarn -s"

Wsrun has this thing called prefixer and it changes my console.log output making it extremely difficult to debug. It's OK if you append the prefix to my output, but if you change stuff - that's not cool.

In particular paths.
It replaced

/home/circleci/repo/contracts/multisig/contracts/multisig/MultiSigWalletWithTimeLock.sol

with

/contracts/multisig/home/circleci/repo/contracts/multisig/contracts/multisig/MultiSigWalletWithTimeLock.sol

If you need more data - I have a repro for that.

I'm using the 2.x version, but 3.x is no different.

i'd like an option to pass flags on to the script.

i.e. something like this: wsrun build --watch or something like that

As per my comment on 833e551, it appears that the runOne method, if mode === parallel reassigns the finished property, meaning the previous assignment of the promise chain that generates the CmdProcess instance is discarded / never executed.

Implement tests with https://www.npmjs.com/package/mock-spawn

I have a private registry and had up till now used the ca field for the certificate in the .npmrc.

Running a script with yarn in each package wasn't a problem but trying to run the scripts in parallel with wsrun resulted in the following error:

TypeError: Cannot create property '' on string '"-----BEGIN CERTIFICATE-----\n...-----END CERTIFICATE-----"'

I moved the certificate to its own file and used cafile instead of ca in .npmrc and now it works.

wsrun version 2.2.0

Would be useful to e.g. run tests on packages that have changed and all their recursive dependents.

We are using wsrun to run the test suites for all packages in our monorepo at once.

While the exit code of wsrun indicates whether all tests succeeded (0), or any of them failed (> 0), it is very hard to establish exactly which package is the culprit. Usually, the individual exit codes for some of the packages have either been pushed out of the terminal buffer, or at least require quite some digging to find.

It would be awesome to get an overview of the results of all included packages after all scripts have been executed. This could e.g. look like that:

...
 | Test Suites: 25 failed, 35 passed, 60 total
 | Tests:       22 failed, 109 passed, 131 total
 | Snapshots:   19 failed, 25 passed, 44 total
 | Time:        22.521s
 | Ran all test suites.
 | Script "test" completed in error: Code 1

package-a: `yarn test` finished successfully (exit code 0)
package-b: `yarn test` finished in error (exit code 1)
package-c: `yarn test` finished successfully (exit code 0)
package-d: `yarn test` finished in error (exit code 2)

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
`yarn test` failed with exit code 1
Done in 29.07s.

That way it's very straightforward to find failing packages, run the command for the individual package and find the underlying issue.

Would that be something you are interesting in/you would accept a PR for?

Snyk is reporting a security vulnerability for the Mem library which is a dependency of Yargs https://snyk.io/test/github/hfour/wsrun.

The suggested fix is to bump Yargs up to at least version 11.1.1

Would be great if you could do this.

Hi,

I found this through your link in microsoft/TypeScript#3469 (comment)

what would be super useful in TypeScript watch scenarios, would be to wait for watch to complete the first compile before starting on the next (possibly parent) file.

As tsc does not clean up the outDir, all our watch commands are prefixes with a command to delete the output directory, such that we start from a clean base and would get compile errors immediately if some packages imports a file which source (TS) no longer exists.

And if a watch exists on a linked project which output dir is removed, tsc gets irrevocably broken.

Therefore it would be a great help if watchs could be started in sequence.

Not sure how TypeScript specific/helpful you would like to make this project, just an idea for now.

I think the output would be more readable if all lines could be prefixed with the package name.

Here is an example of how it looks today with v1.2.3 using --collect-output

$ yarn build2
yarn run v1.3.2
$ wsrun build --stages --collect-ouput
>>> @promaster/edit-plugin-adapter $ yarn build
>>> @promaster/edit-plugin-core $ yarn build
>>> @promaster/example-plugin $ yarn build
$ tsc -p tsconfig-build.json
$ tsc -p tsconfig-build.json
$ tsc -p tsconfig-build.json
@..example-plug | src/index.tsx(2,23): error TS2307: Cannot find module '@promaster/edit-plugin-core2'.
error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
`yarn build` failed with exit code 1
@..edit-p..core | src/plugin-types/area-plugin.ts(1,28): error TS2307: Cannot find module './plugin-base2'.
error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
`yarn build` failed with exit code 1
@..e..p..adapte | src/plugin-adapter.tsx(19,65): error TS1005: ',' expected.
error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
`yarn build` failed with exit code 1
>>> @promaster/plugin-test-runner $ yarn build
$ tsc -p tsconfig-build.json
@..p..test-runn | src/app.tsx(7,4): error TS1005: ',' expected.
error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
`yarn build` failed with exit code 1
✨  Done in 5.83s.

Proposed output:

$ yarn build2
yarn run v1.3.2
$ wsrun build --stages --collect-ouput
@..e..p..adapte | $ yarn build
@..e..p..adapte | $ tsc -p tsconfig-build.json
@..e..p..adapte | src/plugin-adapter.tsx(19,65): error TS1005: ',' expected.
@..e..p..adapte | error Command failed with exit code 2.
@..e..p..adapte | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
@..e..p..adapte | `yarn build` failed with exit code 1
@..edit-p..core | $ yarn build
@..edit-p..core | $ tsc -p tsconfig-build.json
@..edit-p..core | src/plugin-types/area-plugin.ts(1,28): error TS2307: Cannot find module './plugin-base2'.
@..edit-p..core | error Command failed with exit code 2.
@..edit-p..core | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
@..edit-p..core | `yarn build` failed with exit code 1
@..example-plug | $ yarn build
@..example-plug | $ tsc -p tsconfig-build.json
@..example-plug | src/index.tsx(2,23): error TS2307: Cannot find module '@promaster/edit-plugin-core2'.
@..example-plug | error Command failed with exit code 2.
@..example-plug | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
@..example-plug | `yarn build` failed with exit code 1
@..p..test-runn | $ yarn build
@..p..test-runn | $ tsc -p tsconfig-build.json
@..p..test-runn | src/app.tsx(7,4): error TS1005: ',' expected.
@..p..test-runn | error Command failed with exit code 2.
@..p..test-runn | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
@..p..test-runn | `yarn build` failed with exit code 1
✨  Done in 5.83s.

Here is the corresponding output from npm-run-all with the compile errors:

$ yarn build
yarn run v1.3.2
$ run-p -l build:core build:adapter build:plugin build:runner
[build:adapter] $ tsc -p ./packages/edit-plugin-adapter/tsconfig-build.json
[build:core   ] $ tsc -p ./packages/edit-plugin-core/tsconfig-build.json
[build:plugin ] $ tsc -p ./packages/example-plugin/tsconfig-build.json
[build:runner ] $ tsc -p ./packages/plugin-test-runner/tsconfig-build.json
[build:plugin ] packages/example-plugin/src/index.tsx(2,23): error TS2307: Cannot find module '@promaster/edit-plugin-core2'.
[build:plugin ] error Command failed with exit code 2.
[build:plugin ] info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
[build:core   ] packages/edit-plugin-core/src/plugin-types/area-plugin.ts(1,28): error TS2307: Cannot find module './plugin-base2'.
[build:core   ] error Command failed with exit code 2.
[build:core   ] info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
[build:runner ] packages/plugin-test-runner/src/app.tsx(7,4): error TS1005: ',' expected.
[build:runner ] error Command failed with exit code 2.
[build:runner ] info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
[build:adapter] error Command failed with signal "SIGTERM".
[build:adapter] info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
ERROR: "build:plugin" exited with 1.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

I was thinking maybe there are some ideas inside the source code for npm-run-all how to make the yarn output prefixed. It seems to be able to prefix all yarn output except for the last one.

Right now things might hang if packages have cycles.

Yarn happily supports directories being specifically named in the workspaces property of package.json,without any globbing. After a recent commit today wsrun started treating these entries as being directories which contain sub-directories of workspaces. But this is incorrect and doesn't match yarn.

wsrun is often used as below:

{
  "scripts": {
     "build": "wsrun build $PKG --fast-exit -r --stages"
   }
}

allowing for easy CLI selection of the package to build:
PKG=my_package yarn build

The introduction of parameter passing in v3 breaks that compatibility. That functionality was a sole reason that we've been using wsrun rather than lerna. It also breaks other projects such as https://github.com/0xProject/0x-monorepo

I recently used --staged instead of --stages and it took me a while to figure this out. It would be nice, if unknown options could be validated, so an error or warning will be shown. 💖

For example, I have 6 packages, but only 2 have the "start" cmd in the scripts section of package.json. I would like to do yarn wsrun start to start them, but I then get failures for the other 4 packages.

Perhaps it would be possible to pre-check in the package.json of each package and skip the ones that does not have the specified cmd specified?

This is a follow up suggestion for #10.

There could be a set of switches controlling how missing packages are handled:

--error-missing: This is the default and this switch does not need to be specified (and it doesn't even have to exist other than for documentation purposes). If a package is missing it will break with an error without running any of the packages. This is already the default so nothing has to be done (expect maybe add documentation).

--warn-missing: If a package is missing a warning will be printed but all packages that have the script will still be run. This is the same as the existing --exclude-missing (and it could of course keep that name). So it is already done.

--ignore-missing: This is the lerna/oao behaviour. If a package is missing it will be ignored without any warnings. This switch would need to be added.

I'm not generally fond of solving problems by adding more switches but I think most people coming from lerna/oao will want to have the --ignore-missing behaviour to feel at home and be able migrate to wsrun. Existing lerna users have already voiced an opinion towards this in the yarn RFC.

If this would be an accepted approach I could work on a PR for this.

yarn expects the list of workspaces to be under a workspaces property inside packages.json. Right now wsrun just looks at workspace or uses its own defaults. The 's' is the difference.

Other than that wsrun looks exactly the kind of light weight tool I was looking for. (--exclude-missing probably should be a default, but still give warnings.)

Upgrading to 2.1.0 broke my build. A bit of investigation showed that workspaceGlobs in index.js reads 'workspace' not 'workspaces', and doesn't include any of the changes in #18.

const workspaceGlobs = JSON.parse(fs.readFileSync('./package.json', 'utf8')).workspace || [
    'packages/*'
];

A bit more digging showed that the wsrun tarball in the yarn registry includes this change:
wget https://registry.yarnpkg.com/wsrun/-/wsrun-2.1.0.tgz

Hello,

I am trying to run my tests (using jest), but it hangs:

1. normal run

➜  ~/Dev/frontend (dev) yarn wsrun test
yarn run v1.9.4
$ /Users/jozsi/Dev/frontend/node_modules/.bin/wsrun test
project5
$ react-app-rewired test --env=jsdom
project6
$ echo 'No tests here yet'
 | No tests here yet
project4
$ react-app-rewired test --env=jsdom
project3
$ react-app-rewired test --env=jsdom
project2
$ react-app-rewired test --env=jsdom
project1
$ react-app-rewired test --env=jsdom
project5
 | No tests found related to files changed since last commit.
 | 
project4
 | No tests found related to files changed since last commit.
project3
 | No tests found related to files changed since last commit.
project4
 | 
project3
 | 
project2
 | No tests found related to files changed since last commit.
project1
 | No tests found related to files changed since last commit.
project2
 | 
project1
 | 
^CStopping 6 active children

2. using --serial

➜  ~/Dev/frontend (dev) yarn wsrun test --serial
yarn run v1.9.4
$ /Users/jozsi/Dev/frontend/node_modules/.bin/wsrun test --serial
project5
$ react-app-rewired test --env=jsdom
 | No tests found related to files changed since last commit.
 | 
^CStopping 2 active children
/Users/jozsi/Dev/frontend/node_modules/wsrun/build/parallelshell.js:161
                ch.cp.removeAllListeners('close');
                      ^

TypeError: Cannot read property 'removeAllListeners' of undefined
    at children.forEach.ch (/Users/jozsi/Dev/frontend/node_modules/wsrun/build/parallelshell.js:161:23)
    at Array.forEach (<anonymous>)
    at RunGraph.closeAll (/Users/jozsi/Dev/frontend/node_modules/wsrun/build/parallelshell.js:160:27)
    at process.emit (events.js:182:13)

After I build each workspace, I zip each result into the workspace's build/dist folder (my yarn script is called package). For package to work properly, it needs to be executed from the workspace's root dir. Usually, I call cd path/to/workspace; yarn package. Currently, executing wsrun package will not implicitly perform a cd path/to/workspace, so the relative paths used by package/zip are incorrect.

If there is interest in this feature, I can put together a PR

Repro:

wsrun --serial --exclude-missing --fast-exit test:e2e

Hi! Great project! At this time, I'm not able to use it in my project because it doesn't define any license terms, which is a legal requirement for most companies these days.

Please consider adding a permissive license (e.g. MIT).

GitHub makes this really easy:
https://help.github.com/articles/adding-a-license-to-a-repository/

I'm using the ability to run the same command in multiple packages, but some packages does not have the command. I can solve this by the option --exclude-missing which is great, but when you have many packages that do not have the command, the output get cluttered with @foo/bar has no bundle script, skipping missing messages. IMO if you explicitly say --exclude-missing then you don't need to see these warnings every time and it would be cleaner to just skip them.

This is what I get now:

$ yarn bundle
yarn run v1.4.1-20180207.1634
$ wsrun bundle --exclude-missing --collect-output
@foo/edit-client has no  bundle script, skipping missing
@foo/edit-plugin-core has no  bundle script, skipping missing
@foo/edit-server has no  bundle script, skipping missing
@fo/edit-client-emulator has no  bundle script, skipping missing
@fo/edit-plugin-example
$ webpack && cp packages/edit-plugin-example/bundle/index.js ../edit-client-emulator/assets/js/plugin-modules/example-plugin/
@promaster/edit-plugin-adapter
$ webpack && cp packages/edit-plugin-adapter/bundle/index.js ../edit-client-emulator/assets/js/edit-plugin-adapter/
✨  Done in 3.61s.

This is what I would like to see:

$ yarn bundle
yarn run v1.4.1-20180207.1634
$ wsrun bundle --exclude-missing --collect-output
@fo/edit-plugin-example
$ webpack && cp packages/edit-plugin-example/bundle/index.js ../edit-client-emulator/assets/js/plugin-modules/example-plugin/
@promaster/edit-plugin-adapter
$ webpack && cp packages/edit-plugin-adapter/bundle/index.js ../edit-client-emulator/assets/js/edit-plugin-adapter/
✨  Done in 3.61s.

Also, IMO it would be more natural to have --exclude-missing on by default, and maybe have something like --warn-missing or --error-missing to opt in for warnings or error when you want to make sure all packages have the command. But I guess this is a matter of taste, cleaning the output like above would be good enough for me and hopefully something most can agree on.

You seem to be including @types/chalk (a deprecated package) in your dependencies. Mistake or intentional?

Howdy, is it possible to cut a new release that has the fix for #72? Thanks!