Feature request: CLI version

[alessioalex]

Would be great for running demos so you don't have to manually open the browser.

[vweevers]

I'm willing to spend some time on a CLI app. Some thoughts first (also on the cache, because it kinda ties in). In an ideal world:

• browser-launcher2 has a CLI app that lists and/or launches browsers, to ease debugging
• When browser-launcher2 or one of its dependencies is updated, the cache is automatically cleared - kindly preventing a "I installed the new version but nothing changed. What the.. Come on!" post-bugfix rage.
• Users don't need to know the cache even exists
• When you install a new browser, somehow, magically, browser-launcher2 knows about it. But an easy way to manually clear the cache would be okay too

How about (one or more of these) solutions:

• An API function to clear the cache
• A CLI command calling that function, and then add to the readme something like "when you encounter problems or after installing a new browser, run browser-launcher2 clear"
• Adding that command as an npm postinstall script (wouldn't run after npm update though, and sadly there's no postupdate hook)
• Make example/detect.js a CLI command
• A TTL on the cache file
• Check the existence and/or mtime of each browser binary, if changed, clear cache
• But at least: mentioning the cache (and its location) in the readme

What functionality did you have in mind, @alessioalex?

[jakub-g]

What about disabling cache by default? This has a nice feature that if
someone uses the cache, he knows about it. It's pretty nontrivial to figure
out that a lib might have a cache especially if its TTL is infinite. Maybe
even the cache could be not behind a boolean flag, but rather behind a TTL
flag so interested parties can adjust accordingly both presence and TTL by
passing just one arg (default TTL = 0)

On Monday, 4 May 2015, Vincent Weevers [email protected] wrote:

I'm willing to spend some time on a CLI app. Some thoughts first (also on
the cache, because it kinda ties in). In an ideal world:

• browser-launcher2 has a CLI app that lists and/or launches browsers,
  to ease debugging
• When browser-launcher2 or one of its dependencies is updated, the
  cache is automatically cleared - kindly preventing a "I installed the new
  version but nothing changed. What the.. Come on!" post-bugfix rage.
• Users don't need to know the cache even exists
• When you install a new browser, somehow, magically,
  browser-launcher2 knows about it. But an easy way to manually clear the
  cache would be okay too

How about (one or more of these) solutions:

• An API function to clear the cache
• A CLI command calling that function, and then add to the readme
  something like "when you encounter problems or after installing a new
  browser, run browser-launcher2 clear"
• Adding that command as an npm postinstall script (wouldn't run after npm
  update though, and sadly there's no postupdate hook)
• Make example/detect.js
  https://github.com/benderjs/browser-launcher2/blob/master/example/detect.js
  a CLI command
• A TTL on the cache file
• Check the existence and/or mtime of each browser binary, if changed,
  clear cache
• But at least: mentioning the cache (and its location) in the readme

What functionality did you have in mind, @alessioalex
https://github.com/alessioalex?

—
Reply to this email directly or view it on GitHub
#28 (comment)
.

[gregpabian]

I'm willing to spend some time on a CLI app

That's cool, I'd really use some help here 😄

browser-launcher2 has a CLI app that lists and/or launches browsers, to ease debugging

Agree, CLI would be a nice feature to have.

When browser-launcher2 or one of its dependencies is updated, the cache is automatically cleared - kindly preventing a "I installed the new version but nothing changed. What the.. Come on!" post-bugfix rage.

Makes sense - we may use NPM preinstall/postinstall script for that purpose.

When you install a new browser, somehow, magically, browser-launcher2 knows about it.

I'm not sure if you have seen #6 (included in 0.4.5). Currently, when you try to launch a browser that wasn't available while the cache file was created, the file will automatically get updated. And when it comes to the browser detection, it works without the cache, so it won't cause any problems as well.

But an easy way to manually clear the cache would be okay too
How about (one or more of these) solutions: An API function to clear the cache

Check the update() API - it allows you to reset the cache (fill it with present browsers).

mentioning the cache (and its location) in the readme

+1

What about disabling cache by default

Sounds OK, but first we should redesign the flow of the app to be less cache/config dependent (It should only try to detect the browser you really want to launch, not all available ones). Also, we'll need to change the way the profiles are handled (follow the way we handle Firefox right now - use /tmp directory and remove the profile when the instance stops).

Anyway, that's a topic for a separate ticket, so let's focus on CLI here.

We should think how the CLI will look like. My guess would be:

# no arguments - list all available browsers
$ browser-launcher2

# open a URL in a default browser (?)
$ browser-launcher2 "http://google.com"

# open a URL in a specific browser
$ browser-launcher2 "http://google.com" --browser/-b "chrome"
# I'm still not sure how to pass a browser version

# additionally, we'll have to enable some options:
# --proxy/-p <proxy_address>
# --options/-o <additional arguments for the instance>

# and flags:
# --detached/-d
# --headless/-H
# --no-proxy/-n

# update the cache
$ browser-launcher2 --update/-u

# show usage info
$ browser-launcher2 --help/-h

# show current version
$ browser-launcher2 --version/-v

[vweevers]

I would prefer explicit commands, because it makes parsing input easier, avoids confusion, we'll be able to have different flags per command, and it leaves room for future features. In the same order as yours:

browser-launcher2 list
browser-launcher2 launch "http://google.com"
browser-launcher2 launch "http://google.com" -b chrome
browser-launcher2 update

browser-launcher2 --help

# without --help, you'll get usage info as well
browser-launcher2

browser-launcher2 --version

And then also add npm-style shortcuts like

browser-launcher2 l "http://google.com" -b chrome
browser-launcher2 u

[vweevers]

What are the use cases for the CLI?

[alessioalex]

What are the use cases for the CLI?

• npm run demo < run current application in 'demo' / development mode (usually when you want to showcase something)
• npm run test < open the app to run the frontend tests for it

That's two that I can think of.

Edit:

A third one:

• desktop applications that are available as a menu icon and can have the option to open a 'full version' of the application in the browser

[jakub-g]

BTW/FYI: note that I wrapped browser-launcher2 and opener in my biased-opener which has some basic CLI capabilities

# Try opening example.org but only in chrome or opera
biased-opener -b 'chrome, opera' 'http://example.org'

[vweevers]

On second thought, I like yours better, @gregpabian. It's concise and adheres to the "do one thing and do it well" principle. This is a launcher, first and foremost; listing and updating are extras. I forgot that for a moment.

I'll start on a PR soon.

[gregpabian]

@vweevers I'm glad we agree on that, I'm looking forward to see your PR :)

[vweevers]

See #37