Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADD --mute/-m flag to mute GROUPS or TASKS #90

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

serapath
Copy link

This pull request is not mergable yet, but it works.

  1. Probably the way it's implemented is not ok for now.
  2. I also did not update any readme's yet.
  3. Who knows how the "API" should look like

...but i really would like to have this feature.

Use Case

Every time i need to run a combination of tasks, like for example:

  • a static http server
  • a selenium server for testing
  • run a test suite
  • maybe a live-reloading thing
  • ...

I would like to just type npm start or npm test and everything that needs to start starts.
I would also like to have logging of the important stuff and quit all those processes when i want.

npm-run-all does that, but when all those processes log to the terminal, i dont see what i consider important, so i'd like to be able to mute the tasks i dont want to see.

Example

{
  "scripts": {
    "AAA": "echo AAA",
    "BBB": "echo BBB",
    "YO": "echo YO",
    "A": "echo A",
    "YO": "echo YO",
    "test": "npm-run-all -nsm AAA -pl BBB AAA BBB -mlpr --silent YO -m --silent A B -s --mute AAA -- --asdf 5"
  }
}

So npm test will mute:

  • all tasks of group 1 ['AAA'] because -nsm has -m after -s
  • the last task 'BBB' of group 2 ['BBB', 'AAA', 'BBB'] because of -mlpr has -m before -p
  • task 'YO' of group 3 ['YO', 'A', 'B'] because of -m after YO
  • all tasks of group 4 ['AAA'], because of --mute after -s

@mysticatea
Copy link
Owner

mysticatea commented Mar 18, 2017

Thank you for this request and implementation!

Hmm, but the option looks cryptic to me.
I think nested options make less readability since CLI arguments does not have flexible structure, it's just linear.

I'd like to separate the --mute option.

$ npm-run-all --serial a b c --mute b

This will mute the task "b".

Also isn't implementation enough if it set null ("ignore") to the stdout and stderr of spawn's option?

@serapath
Copy link
Author

i don't know. I tried that, but for some reason there were so many complications and errors.
In theory i imagine that should be enough, but because it's connected to a TTY - it might be more complicated. I did not succeed finding an easier solution. Everything i tried to mute stuff didnt work.

In general i consider to build my own version of npm-run-all that i plan to call wireup.
The main reason behind it is - i want a cli-module that can be also used programmatically, that enables me to execute multiple processes (parallel and serial) and set up arbitrary ways in which i can pipe results between them.

The foundation regarding the command line usage that i plan is the module subarg which allows nested command line arguments following the same syntax as minimist ... but nested.

In my opinion, that would make it a lot more clear how command line options can be passed.

I already was confused about the current option of --silent and --race which seem to not be group specific but global option unlike --parallel which seems to work on all tasks that follow after the option until the next --parallel or --serial appears.

The --mute option that follows a --serial/--parallel option is meant to affect the whole group.
The --mute opton that follows a task but preceds another group is meant to mute the last task.
That's how this pull request currently tries to work.

Your proposal above would mean always the next upcoming task should be "muted", but what about a ...if a would be muted, then how could i mute the whole group?
... i feel without something like using subarg (see above) passing group specific arguments in general could be messy.

Then - on the other hand - switching npm-run-all to use subarg (which is what i plan for my own module) - would be super awesome and adding the "pipe feature" would be even more awesome - but regarding the usage of the cli-api would probably be a breaking change.

@serapath
Copy link
Author

serapath commented Apr 3, 2017

I'm still interested in this pull request.
I see that tests are failing, but I can update everything again. I'm just wondering about the proposal in general. Is that a wanted feature? :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants