Command-line arguments are not passed on macOS

[wesleycoder]

I use this cli to pass args via npm scripts like:
opn http://localhost:4200 -- 'google-chrome' --user-data-dir=.tmp-chrome --remote-debugging-port=9876
But on MacOS Mojave it doesn't works, I think it is because the browser is named diferently on the OS.

But even when passing:
opn http://localhost:4200 -- 'Google Chrome' --user-data-dir=.tmp-chrome --remote-debugging-port=9876
The browser doesn't start.
Calling opn http://localhost:4200 -- 'Google Chrome' it opens the browser.

My necessity is to open another instance of the browser with a profile scoped to the .tmp-chrome folder.

I've wrote a simple script as a workaround to use on my project, but I think this package could solve this problem more elegantly.

#! /usr/bin/env node
const opn = require('opn')
const childProcess = require('child_process')

const plat = process.platform

if (plat === 'darwin') {
  const cp = childProcess.spawn(
    '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
    [
      '--user-data-dir=.tmp-chrome',
      '--remote-debugging-port=9876',
      'http://localhost:4200',
    ]
  )

  cp.unref()

  process.exit(0)
} else {
  const browser = plat === 'win32'
    ? 'chrome'
    : 'google-chrome'

  opn('http://localhost:4200', {
    wait: false,
    app: [
      browser,
      '--user-data-dir=.tmp-chrome',
      '--remote-debugging-port=9876',
    ],
  })
}

There is a $40.00 open bounty on this issue. Add more on Issuehunt.

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on Issuehunt to raise funds.

[IssueHuntBot]

@IssueHunt has funded $40.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[ankurkaushal]

@wesleycoder For some reason I couldn't reproduce some of the scenarios you mentioned in the issue:

• open-cli http://localhost:4200 -- 'google-chrome' --user-data-dir=.tmp-chrome --remote-debugging-port=9876 --> Doesn't work as expected.
• open-cli http://localhost:4200 -- 'Google Chrome' --user-data-dir=.tmp-chrome --remote-debugging-port=9876 --> Works
• open-cli http://localhost:4200 -- 'Google Chrome' --> Works

I am on Mac OS X Mojave (10.14.5) too.

May be I am unsure of what you're expecting open-cli to do, can you explain? :)

[wesleycoder]

open-cli http://localhost:4200 -- 'google-chrome' --user-data-dir=.tmp-chrome --remote-debugging-port=9876 --> Doesn't work as expected.

• This will not work cross environments because open-cli doesn't know how to deal with differences between OSs on the binary name, and maybe would be possible to implement it.

open-cli http://localhost:4200 -- 'Google Chrome' --user-data-dir=.tmp-chrome --remote-debugging-port=9876 --> Works

• This should start the google-chrome browser with a blank profile saved to a .tmp-chrome on the current working directory and with the remote debugging port set to 9876, but instead it opens a new window on the current profile of the browser because open-cli doesn't pass the -- parameters to the google-chrome instance upon starting correctly.
  The code snippet on the issue descriptions does this with the opn lib.

open-cli http://localhost:4200 -- 'Google Chrome' --> Works

• This will work ok since we are passing the name of the binary correctly and no cli flags.

Let me know if I can provide more info or help with anything.
Thanks for looking into the issue.

[dfahlander]

I have the same issue. The issue seems to be, at least for the --incognito argument, it has to be passed differently to the native "open" cli on Mac in order to be respected.

The current libary uses "open" library that calls the native "open" CLI on mac as follows:

open -a "Google Chrome" "http://localhost:4200" "--incognito"

But in order for --incognito to be respected, one has to start a new instance and pass the URL among the arguments instead:

open -na "Google Chrome" --args "http://localhost:4200" "--incognito"

I was about to fix this in the source but I'm out of time as it also would require a change on the "open" package that this depends on.
In my case I could fix it using a custom CLI. But if anyone else is eager to fix this, look in the open library on index.js, lines 51-63 where it pushes arguments to the native open. That library would need to be extended to allow "-na" flag instead of "-a" and then this library could use that argument and pass the URL among the arguments instead.

[itaisteinherz]

@dfahlander Seems like sindresorhus/open#253 added the option required in order to fix this in the CLI, right?