# Workspaces Deep Dive

### Attendees
- Darcy Clarke (@darcyclarke)
- Ruy Adorno (@ruyadorno)
- Christian Siebmanns (@christian24)
- Nathan LaFreniere (@nlf)
- Isaac Z. Schlueter (isaacs)
- Bradley Farias (@bmeck)
- Jordan Harband (@ljharb)

#### Notes
- @ljharb run arbitary commands
- @darcyclarke does `npm exec` work
- @christian24 `git submodule foreach ...`

#### Actions
- [ ] add `exec` to the subcommand list
- [ ] update to reference top-level `ws/workspaces` command over `-w/--workspace`

#### Examples / Usecases

# making it a top level 'ws' command
$ npm ws exec -- cat package.json
$ npm ws exec -w foo -- cat package.json
$ npm ws exec --all -- cat package.json

# making it a flag '-w' or '-ws'
$ npm exec -w foo -w bar -w baz
$ npm exec -ws 

# spec'ing a "foreach" ...
$ npm workspace foreach npm test
$ npm workspace foreach cat package.json

# learna's implementation...
$ learna exec cat package.json

- `ws|workspaces` top-level command avoids the hazard of users trying to run a command that is just not supported and we can just throw an error in these cases
- Syntax for running a subcommand across all workspaces becomes more aligned with other commands we have, e.g: `--all`
- open question: do we run ws commands in parallel? (Interleaving output, stdin stuff, etc. Maybe good to opt-in though, for cases where it does make sense?)