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 app constants for popular apps #116

Closed
sindresorhus opened this issue Mar 16, 2019 · 14 comments · Fixed by #222
Closed

Add app constants for popular apps #116

sindresorhus opened this issue Mar 16, 2019 · 14 comments · Fixed by #222
Labels
enhancement 🎁 Rewarded on Issuehunt This issue has been rewarded on Issuehunt help wanted

Comments

@sindresorhus
Copy link
Owner

sindresorhus commented Mar 16, 2019

Issuehunt badges

App binaries have different names on different platforms. This complicates opening a certain app in a cross-platform manner. We could add some constants for popular apps:

open('https://sindresorhus.com', {app: open.apps.chrome});

https://github.com/sindresorhus/opn/blob/5c525b5f4f2472e35ace19d6df746bb355b8060a/test.js#L5-L17

Feedback welcome on how it should look like.


IssueHunt Summary

richienb richienb has been rewarded.

Backers (Total: $40.00)

Submitted pull Requests


Tips

@IssueHuntBot
Copy link

@IssueHunt has funded $40.00 to this issue.


@stroncium
Copy link

stroncium commented Mar 25, 2019

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].)

@sindresorhus
Copy link
Owner Author

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

@stroncium
Copy link

@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[]>)

@sindresorhus
Copy link
Owner Author

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'}.

@Richienb
Copy link
Contributor

Richienb commented Feb 5, 2021

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?

@sindresorhus
Copy link
Owner Author

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.

@Richienb
Copy link
Contributor

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

@sindresorhus
Copy link
Owner Author

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

@Richienb
Copy link
Contributor

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

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

@sindresorhus
Copy link
Owner Author

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

@issuehunt-oss
Copy link

issuehunt-oss bot commented Mar 2, 2021

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

  • 💰 Total deposit: $40.00
  • 🎉 Repository reward(0%): $0.00
  • 🔧 Service fee(10%): $4.00

@issuehunt-oss issuehunt-oss bot added 🎁 Rewarded on Issuehunt This issue has been rewarded on Issuehunt and removed 💵 Funded on Issuehunt This issue has been funded on Issuehunt labels Mar 2, 2021
@sodatea
Copy link

sodatea commented Mar 12, 2021

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

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

@ammmze
Copy link

ammmze commented Apr 8, 2021

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement 🎁 Rewarded on Issuehunt This issue has been rewarded on Issuehunt help wanted
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants