Add app constants for popular apps #116

@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.

I propose to treat app/app[0] as string | () => (string | Iterable<string>) (typescript). Iterables could be just arrays, but it sounds like weird limitation. Then for example chrome app would be defined as

() => {
  if(isWsl) return ['Chrome'];
  switch(process.platform){
    case 'darwin': return 'google chrome canary';
    case 'win32': return 'Chrome';
    case 'linux': return ['google-chrome', 'google-chrome-stable', 'google-chrome-beta', 'google-chrome-dev'];
    default: throw new Error('platform ${process.platform} not supported');
  }
}

Note linux case, that's why iterable. (At least Arch linux doesn't have google-chrome unless simlinked manually. Guessing from value for darwin it might be the case for it too.)

(We can't provide Iterable without function, as in that case we won't be able to decide if app is app or [app, ...args].)

@stroncium I do like your suggestion on it being just a function. I think the function should receive the target argument so it's possible to do custom behavior for different types of input.

Your proposal doesn't account for situations when the apps for different platforms require different arguments. How about we move from using an array to an object when app arguments are required? So instead of ['google-chrome', '--incognito'] it would be {name: 'google-chrome', arguments: '--incognito'}.

@sindresorhus Well that was my first idea, but I was thinking about making it full backward compatible here. Anyhow...

app becomes string | string[] | (string[] => Iterable<string[]>) args is string[]

1. for app string we go with exec([app, ...args])
2. for app Array we go with exec([...app, ...args])
3. for app function we go with for(list of app(args)) exec(list) until success

Do we want to handle 2 this way for backward compatibility or just make it an error or check for args and make an error if they do exist? In latter case we can reduce app type to string | (string[] => Iterable<string[]>)

Backwards-compatibility seems complicated. We can do a major version.

I want:

So instead of ['google-chrome', '--incognito'] it would be {name: 'google-chrome', arguments: '--incognito'}.

Backwards-compatibility seems complicated. We can do a major version.

I want:

So instead of ['google-chrome', '--incognito'] it would be {name: 'google-chrome', arguments: '--incognito'}.

Do we still want app to accept a single string?

Do we still want app to accept a single string?

I guess it doesn't hurt to continue supporting it. We can remove it from the docs though and comment in the code that it should be removed at some point.

In the example, Linux has 4 different binaries to call. How will the code detect which one to use?

Those are different Chrome editions. They would have different constants.

Those are different Chrome editions. They would have different constants.

The first 2, google-chrome and google-chrome-stable are the same.

I guess we'll have to open the most likely one and if it fails, try the second one.

@sindresorhus has rewarded $36.00 to @richienb. See it on IssueHunt

• :moneybag: Total deposit: $40.00
• :tada: Repository reward(0%): $0.00
• :wrench: Service fee(10%): $4.00

    case 'darwin': return 'google chrome canary';

Is it a typo to use Chrome Canary on macOS, while on other platforms it's just Chrome?

    case 'darwin': return 'google chrome canary';

Is it a typo to use Chrome Canary on macOS, while on other platforms it's just Chrome?

It appears so. I'm on macOS 11.2.2 and google chrome canary doesn't work, but google chrome does. So using { app: apps.chrome } is broken for me on macOS.