Don't pass bnr flags to specified command

[laverdet]

Currently bnr-specific flags are forwarded to the ran command which seems like a pretty bad idea.

Consider package.json:

{
  "scripts": {
    "hello": "bnr hello -s"
  },
  "betterScripts": {
    "hello": {
      "command": "node hello.js"
    }
  },
  "dependencies": {
    "better-npm-run": "0.0.15"
  }
}

And hello.js is just console.log(process.argv).

Running npm run hello will output:
[ 'node', 'hello.js', '-s' ]

This is undesirable because if the command you are running also has some kind of meaning assigned to these flags then you can't use bnr.

This pull request allows you to put bnr flags before the specified command. Those arguments will be consumed by bnr and then the command only gets arguments which appeared after. This shouldn't break existing applications because the behavior remains the same for the old way. I've updated the README with the preferred way of passing flags.

If you don't mind breaking existing applications (major semvar update), then a more correct fix would be to have bnr ignore the flags after the specified command and just forward them. Perhaps you can do that some time in the future after landing this patch.

[galenandrew]

@laverdet thank you for your PR!! This change makes sense to me and looks like it will resolve #68.

@benoror thoughts?

[benoror]

lgtm

[galenandrew]

@benoror this looks like it would be a breaking change since it's changing the order of arguments in users' package.json. Thoughts on a major version bump – v1.0.0?

[laverdet]

It doesn't break existing invocations, actually. If the paramters appear after the invoked script they are passed forward and interpreted by bnr (matches current behavior). If they are passed before the script they are consumed and not passed forward. Before the patch, flags before the script would be an error.

I mentioned in the original comment that a more a correct solution would be to not interpret flags after the script.. but that would be a breaking change which seemed to aggressive for a random pull request.

[galenandrew]

@laverdet thanks for the clarification…you're right.

[benoror]

@laverdet thanks!