caspervonb / node-browser_process

Cross platform browser process creation

node-browser_process

Cross platform and uniform browser detection, command line arguments handling and process launching of chrome, chromium, electron and firefox for node.js.

INSTALLATION

npm install [--save] browser_process

USAGE

const browser = require('browser_process');

const args = browser.options('chrome', {
  url: 'about:blank',
});

browser.spawn('chrome', args, (error, ps) => {
  if (error) {
    return console.error('Unable to launch chrome (%s)', error);
  }

  console.log('Launched chrome (%s)', ps.spawnfile);
});

DOCUMENTATION

See the documentation

SUPPORT

• If you need help, ask in the chat.
• If you found a bug, submit an issue.
• If you have an idea, submit an issue.
• If you’d like to ask a general question, issue.
• If you want to contribute, submit a pull request.

RELEASES

See the changelog.

LICENSE

The project is licensed under the MIT License.

node-browser_process's Issues

No `version` or `--help` output from windows browsers

$ chrome.exe --version
# no output, instead the browser is launched.

$ firefox --version
# no output, no launch.

Which breaks the new behavior of type introduced in b7806a1

lib: extract electron-browser to a standalone module

Instead of just throwing an error when electron is given an .html file, we open it with a very minimal shim called 'electron-browser, which lives inlib/electron-browser.js` ()

Extract that file into its own standalone module.

travis: enable windows testing

We should enable travis to do windows tests.

But wait, travis does not support windows, true however we can make travis dispatch to appveyor. Making the build status centralised to one location.

When you specify a OS that doesn't exist, travis boots into linux so it's a neat hack to run off-site tests.

buildkite: use buildkite for builds and tests

Buildkite is way more manageable than having to manage both travis and appveyor, however this is more long term than immediately as I don't have the hardware to run agents for all the required operating systems available at the moment.

Add support for launching Microsoft Edge

In order to launch Microsoft Edge, we are providing https://github.com/MicrosoftEdge/edge-launch, and edge-diagnostics-launch when remote debugging is needed to be enabled.

The process for launching Edge is slightly different than other browsers, as our binaries doesn't support flags directly, and remote debugging is happening via a protocol adaptor.

Add windows continuous integration

Currently there's only Linux coverage with travis-ci, add appveyor as the windows service.

lib: resolve paths into real paths

Currently we are resolving into realpaths in spawn, while it works this is hard to test. Better would be to just resolve the executable paths in the functions that return executable paths (find, findSync, detect and detectSync).

Support Electron

Recognise electron as a browser, at this point It' be better to split browsers into types, and names.
E.g chrome, chromium, electron are all of type chrome browsers, their flags are mostly compatible, but their names are different.

node-browser_process.js.org

JS.ORG CLEANUP

Hello, it seems a js.org subdomain that was requested to target this repository (or another on this user/organisation) no longer works.
The subdomain requested was node-browser_process.js.org and had the target of caspervonb.github.io/node-browser_process.
To keep the js.org subdomain you should add a page with reasonable content within a month so the subdomain doesn't resolve to a 404 any longer.
Otherwise the requested subdomain will be removed from JS.ORGs zonefile and the list of active subdomains.

If you are wanting to keep the js.org subdomain and have added reasonable content, YOU MUST reply to the main cleanup issue with the response format detailed at the top to keep the requested subdomain.

lib: fix spawn callback

Alright no idea why I've missed this for so long, but the spawn callback is actually completely wrong.

    process.nextTick(function () {
      ps.removeListener('error', callback);
      callback(null, ps);
    });

If an error occurs before nextTick, what's going to happen? The callback will be called twice.

doc: write pandoc compatible manuals

While ronn(1) is great, it is not under active development, in-fact it has bugs that's been open for years. Where-as pandoc(1) is under very active development and is more widely used.

So, documentation should be converted to pandoc compatible markdown.

doc: generate manual pages

We have man(1) like markdown pages, we can generate real man pages with pandoc(1) to distribute with the package.

test: check path resolution with a mock file-system

Current tests are checking the real file system, and they are just checking for success which is okay but we should really also test with a mock file system to ensure that the paths are the ones we expect.

Better type detection

Currently type detection is based on executable name, better to parse --version in order to figure out what kind of browser it is.

test: enable osx for travis

Travis has enabled multi-os for all repositories now, it's time to enable multi-os testing for travis.

Follow symlinks

Symlinks won't work, brew cask installs everything with symlinks.
So this should be supported.

Fix chromium lookup

The Chromium is actually typically called chrome.exe on windows, so a which lookup is not enough.

doc: formatting parameter lists

GitHub flavored markdown does not provide any sort of definition lists, which is somewhat of a pain when it comes to documenting command line options and function parameters.

With pandoc(1), you can define definition lists with the following syntax

`callback`
:   
    Specifies the function which is called once the file read
    is done with the following parameters:

    `error`
    :   
        Specifies the error object indicating which error
        occurred, undefined if no error occurred.

    `buffer`
    :   
        Specifies the buffer containing the data read from
        the file.

Which renders into the following html:

callback

Specifies the function which is called once the file read is done with the following parameters:

error

Specifies the error object indicating which error occurred, undefined if no error occurred.

buffer

Specifies the buffer containing the data read from the file.

If we change those definition lists terms into actual lists like the following:

* `callback`
:   
    Specifies the function which is called once the file read
    is done with the following parameters:

    * `error`
    :   
        Specifies the error object indicating which error
        occurred, undefined if no error occurred.

    * `buffer`
    :   
        Specifies the buffer containing the data read from
        the file.

This will render into nested lists, and because two spaces are considered a hard line break. The definition list turns into space, colon, <br>, which will render as the following:

• callback :
  Specifies the function which is called once the file read is done with the following parameters:

  • error :
    Specifies the error object indicating which error occurred, undefined if no error occurred.

  • buffer :
    Specifies the buffer containing the data read from the file.

Except for the bullet points it renders almost identical, most importantly, it's a very simple, global transformation that can easily be done with sed(1), the raw regex would look something like \*\s(.*\n.*\:\s{3}).

Why not just keep the nested lists and style it accordingly? Well, semantics. In this case semantics matter when transforming to for example, groff.