Parameter/argument passthrough about npm-run-all HOT 22 CLOSED

@mysticatea

cmd.exe doesn't remove \ since it just a path separator, so run-p "a -- $1" is parsed to ["node", "run-p", "a -- $1"].

This is correct behavior. Since \ is used for escape $. I have implemented such as.

@keeganstreet
You can do it in this way.

{
  "serve": "npm-run-all --parallel css \"mm $1\" --"  # the last -- is a separator for npm-run-all
}

$ npm run serve -- --port=4567      # the middle -- is a separator for npm

And you can do anything that you want

• "serve": "npm-run-all --parallel css \"mm --port=$1\" --" then do $ npm run serve -- 4567
• "serve": "npm-run-all --parallel css \"mm --po$1\" --" then do $ npm run serve -- rt=4567
• "serve": "npm-run-all --parallel css \"$0\" --" then do $ npm run serve -- mm --port=4567

from npm-run-all.

Thank you for this issue.

Hmm, you cannot pass it, now.

npm run serve -- --port=4567 is evaluated as npm-run-all --parallel css mm --port=4567 by npm. But we need npm-run-all --parallel css "mm -- --port=4567" in order to give the argument to mm.

from npm-run-all.

One workaround for my issue would be to use npm configuration parameters. For example if this is my package.json:

{
  "name": "keegan",
  "config": {
    "port": "4567"
  },
  "scripts": {
    "css": "grunt watch:css",
    "mm": "bundle exec middleman --port=$npm_package_config_port",
    "serve": "npm-run-all --parallel css mm"
  }
}

I can then call npm run serve --keegan:port=5000, and the mm script will receive the custom value of 5000 as a port.

However, this will only work on Bash not the Windows Command Shell, which references variables with a % sign not a $ sign. To get this to run on Windows I would need to change the mm script to bundle exec middleman --port=%npm_package_config_port%.

So I still think it would be a great feature for npm-run-all to be able to pass arguments to scripts from the command line.

from npm-run-all.

Yeah, I made npm-run-all passing --keegan:port=5000-like arguments to each script in #13.
You can use cross-conf-env to use $npm_package_config_ variables on cross platform.

To go forward this feature, there are some problems:

• npm-run-all cannot distinguish where did an argument come from. process.argv does not tell me that.
• If npm-run-all handles unknown options (such --port) as an argument that it pass to scripts, I loose the ability to add new CLI option without a breaking change.

from npm-run-all.

Thanks @mysticatea, I've confirmed that cross-conf-env allows this to work cross platform. I just have to change my mm script to cross-conf-env bundle exec middleman --port=npm_package_config_port and then I can call npm run serve --keegan:port=5000 and the port argument is passed through on both Mac and Windows.

I understand it would be difficult to design a way to pass arguments through to the correct child script. Feel free to close this issue. The workaround with npm config params solves my use case.

from npm-run-all.

@mysticatea @keeganstreet
I also have the same problem.
I suggest that it is able to include like $1,$2,...,$n similler to a shell script.
If $ causes a problem, it may be in a different symbol.
What do you think?

from npm-run-all.

@mysticatea @keeganstreet

I've implemented the concept.
robario@74f720e
Please check it.

It enables below.

$ run-p 'task1 -- $2 $1' 'task2 -- $0' -- one 't "w" o'

> task1  "t \"w\" o" "one"
> task2 "one" "t \"w\" o"

• $0 is a bonus feature to be able to specify all the rest aruments.

from npm-run-all.

Wow, great idea!
It's understandable, and it can control destinations of arguments.

Hmm, but it has a problem of compatibility with Windows.
$1 is a valid environment variable, so it needs to be enclosed in single quotes or be escaped by \, but I guess it causes a problem on cmd.exe. npm run command is using cmd.exe on Windows.

• cmd.exe doesn't handle ' as enclosing characters, so run-p 'task1 -- $2 $1' is parsed to ["node", "run-p", "'task1", "--", "$2", "$1'"].
• cmd.exe doesn't remove \ since it just a path separator, so run-p "a -- \$1" is parsed to ["node", "run-p", "a -- \$1"].

Alternative:

• !1 - needs to be escape.
• #1 - needs to be escape.
• %1 %2 - seems an environment variable %1 % on cmd.exe.
• &1 - needs to be escape.
• ^1 - needs to be escape on cmd.exe.

maybe ~1 or @1 or /1?

from npm-run-all.

@mysticatea
Sure, it is just a concept implementation.
If you have consensus about this idea, I want to continue to realize it.

from npm-run-all.

Thank you.
The idea sounds good to me. 😄

from npm-run-all.

Okay, thank you ❗
I will review of your comment now.

from npm-run-all.

Hey @robario,

I'm just trying to understand your interface design. In your design and my use case, would the npm scripts be written like this?

"scripts": {
  "css": "grunt watch:css",
  "mm": "bundle exec middleman",
  "serve": "npm-run-all --parallel css \"mm $1\" -- --port=4567"
}

(with $ symbol to be confirmed)

from npm-run-all.

@robario That's about process.argv.
node test.js \$1 is parsed to:

• On sh, ["node", "test.js", "$1"]
• On cmd.exe, ["node", "test.js", "\$1"]

There is a difference.
Because \ is not an escape character on cmd.exe. It's just a path separator. But on sh, it's an escape sequence.

from npm-run-all.

@mysticatea I got it. Thanks.

from npm-run-all.

@mysticatea @keeganstreet

As you pointed out, I think $ will cause a problem.

It is better that are similar to other languages, also it is better to think also scalability.
POSIX(C, Java, PostgreSQL,and so on) has been adopted %1$d,%2$s,... syntax.
On the other side, C#, Python has been adopted {0},{1},... syntax.

In order not to use $, I think the {index} syntax is better.
It is also scalable in this way :: {index,specifications}

Well, there may have to be some decisions.

• How to escape when a user really want to pass {3} to npm run-script?

  I think it is better not to use backslash.
  One way, the user can avoid by himself.

  "serve": "npm-run-all --parallel css \"mm {1}\" -- '{3}'"`
  

  It is simple and can be resolved with documentation, no need implementation.

• Which do you want to adopt a 0-origin or 1-origin index?

  My opnions

  In consideration of the usage of this program, I want a way I pass all to npm run-script.
  Since I want to use {0} for it, I think that 1-origin is good.

  Otherwise, using special index and use 0-origin like Python, C#.
  The candidates are

  • {@} from shell script $@ :: well..., I prefer this way! but $@ equals to $1 $2 $3 ... is 1-origin...
  • {%} from vim %
  • {} :: see bellow
  • {-0} :: see bellow
  • {-1} :: see bellow

• In association with,

  • Whether or not to adopt auto index like as "{} {}".format('hoge', 'hage')
  • Whether or not to adopt negative index like as "{-1} {-2}".format('hoge', 'hage')
  • Whether or not to adopt named argument like as "{foo} {bar}".format(foo='hoge', bar='hage')

How about?

from npm-run-all.

I recommend to use 1-origin and special index {@} and {*} like shell-script.
It can keep npm-run-all's code simple.
I'm trying implements.

from npm-run-all.

I did it. robario@09e7c1e

Please try this and review.
repo: https://github.com/robario/npm-run-all/tree/master
diff: master...robario:master

Perhaps there are quote problems on Windows.
I think it should use another library which can interpret metacharactors of cmd.exe and sh instead of shell-quote.

from npm-run-all.

One more thing.

• Whether or not to quote arguments.
  1. traditional behavior of shell script
     • run-s "echo {1}" -- "foo bar" => echo foo bar
     • run-s "echo \"{1}\"" -- "foo bar" => echo "foo bar"
  2. easy to use for the user. But the user can not control.
     • run-s "echo {1}" -- "foo bar" => echo "foo bar"
     • run-s "echo \"{1}\"" -- "foo bar" => echo "\"foo bar\"" :: this result is correct, usually will be not used
     • ? => echo foo bar :: can not control means this behavior

There are same things about {@} {*}. In shell-script $@ and "$@" are different.

My recommendation is the second.
And, upon request, provide a special syntax like ...{1} or {1,raw|noquote} to be able to control it.

from npm-run-all.

@robario Make sense, I like this spec and this implement. ❤️

• How to escape when a user really want to pass {3} to npm run-script?
  ...

OK as there is a way to avoid.

I recommend to use 1-origin and special index {@} and {*} like shell-script.
It can keep npm-run-all's code simple.

I agree.
Good sense 😉

Perhaps there are quote problems on Windows.
I think it should use another library which can interpret metacharactors of cmd.exe and sh instead of shell-quote.

There seems to be no issue for Windows on shell-quote repo.

Or, I guess that the same way as npm is no problem hopefully.
It's simple: https://github.com/npm/npm/blob/9dd4848bbcbae1c1d8778dc51cd88c8b5d771c71/lib/run-script.js#L174

My recommendation is the second.

I agree.
npm run-script encloses each argument by double quotes.

And, upon request, provide a special syntax like ...{1} or {1,raw|noquote} to be able to control it.

This notation is extensible. 😄
Anyway, I think the current implementation is the very good start.

from npm-run-all.

@mysticatea Thank you for your comments and advices.
Repeated, I appreciate your decision and accepting it.

Since roughly seems like no problem, I will send pull-request later.

BTW, It’s hard for me to say this but could you please add the documentation and tests?

from npm-run-all.

BTW, It’s hard for me to say this but could you please add tests and documentation?

Haha, OK, I will do. 😄
I appreciate your idea and implementation.

from npm-run-all.

Awesome thanks to all!

Although most similar to the positional parameters of shell-script, these are to be careful when you update the document and test.

• {@} is similler to "$@" not $@
• {*} is similler to "$*" not $*
• {1} is similler to "$1" not $1

If someone needs unquoted version, then another syntax is necessary for solving it.

from npm-run-all.