Odd behaviour when spawning ghostface with child_process.spawn about ghostface HOT 3 OPEN

Hmm; I haven't tried this, but I bet this is due to how ghostface detects if it should expect input on stdin (say via a cat somefile.js | ghostface) and it's probably just hanging waiting for input. See this line https://github.com/fardog/ghostface/blob/master/lib/cli.js#L89

This isn't ideal, and I'll leave this issue open and check into it further. However for your use case, you may find it much simpler: ghostface is actually requireable, I just haven't documented this yet.

var fs = require('fs')
var path = require('path')
var ghostface = require('ghostface')

var options = {
  html: path.join(__dirname, 'file.html'),
  timeout: 1000,
  input: fs.createReadStream(path.join(__dirname, 'file.js')),
  phantomPath: '/usr/sbin/phantomjs'
}

ghostface(options, process, function(code, signal) {
  if(code > 0) {
    console.error(sprintf('\nphantomjs exited abnormally: %d'), code)
  }

  process.exit(code || signal === 'SIGTERM' ? 0 : 1)
})

…admittedly, this is not a very clean interface, but it wasn't intended for public consumption (yet!). Let me know if you think that'll work for you, and like I say, I'll leave this issue open as a reminder to:

• Document the programatic interface
• Figure out what the root of this bug is

from ghostface.

oh, and a quick note on the above: the process object that I pass in, you could construct yourself, it just wants something that takes this shape:

{
  stdin: readableStream,
  stderr: writableStream,
  stdout: writableStream
}

You don't have to specifically pass in the process object, but that's possibly easiest for what you're looking to do. You can see how I very simply mock this object in the tests: https://github.com/fardog/ghostface/blob/master/test/index.js#L175

from ghostface.

This actually does work for my situation. Thank you!

While it isn't ideal, it works for me. And while I can personally work around the issue, maybe other people won't be able to, so keeping the issue open is probably a good idea :D

Also, piping into the CLI is what I tried to do initially, and it works for me too, except even that wasn't exiting with proper error codes either. BUT I filed a bug report for that.

Super cool that this can be used with a require!
Thanks again.

from ghostface.