Open Offirmo opened 6 years ago
Weird, I thought we were already doing that.. or is it just for exec?
I'm gonna take a quick look into this tomorrow morning.
What I'm seeing on my local machine matches this issue, but 100% does not match what we seem to see in CI.
Just for my own notes:
Workspace run calls yarn.runIfExists (https://github.com/boltpkg/bolt/blob/master/src/commands/workspaces/run.js#L38)
Which just calls yarn.run (https://github.com/boltpkg/bolt/blob/master/src/utils/yarn.js#L79)
Which doesnt do anything special but call processes.spawn using the relative path to the local yarn (https://github.com/boltpkg/bolt/blob/master/src/utils/processes.js#L44)
I have a feeling the issue is on (https://github.com/boltpkg/bolt/blob/master/src/utils/processes.js#L72) where we check for child.stdout. I'm not sure exactly what makes this sometimes be null except that it seemed to always happen when running in a subshell.
e.g
(cd example && ../bin.js ws run prepublish)
Hi @lukebatchelor , I'm still hindered by this issue. Would love a solution! Should I try to contribute?
Sure, that'd be great. It's not something we've ever used since we don't use any scripts within packages, we just use exec from the root, which does what you're after. If you could make it work similar to that, that'd be fantastic
Feature request: enhance bolt output to discriminate between concurrent workspace commands
Right now when executing a multi-workspace command, it's hard to know what's going on, especially since commands are executed concurrently.
Example 1:
What workspace caused this error? It's not easy to tell...
Example 2:
That would be extremely convenient to be able to know which workspace is the source of each line...
Maybe a prefix?