self-hosted files

[timoxley]

Rather than piping into smokestack which boots up a server and hosts the content for you, maybe could tell smokestack to navigate to a particular page and use extension power to inject the instrumentation that speaks back to the server.

e.g.

> node server.js --port 9000 &
[1] 80970
> smokestack http://localhost:9000 | tap-spec
 setup
  should be good
    ✓ is good
    ✓ is not bad

  shudown

  tests 3
  pass  3

  Pass!
> 

[hughsk]

I think is out of scope for smokestack, it'll complicate the codebase a lot trying to get this working alongside our current code.

That being said, I also think this would be super useful. I think what would be best here would be to eventually write another thing that takes a URL like above and does all of smokestack's instrumentation stuff. If we go down that route, smokestack could end up just being a thin wrapper around that tool.

[timoxley]

Thinking this is super limiting because many api-like scripts will assume they're being served from the same host that they're supposed to be hitting for API calls. e.g. many clients will look like this: href="/api/stuff" vs href="http://localhost:9000/api/stuff"

I'm thinking the easy solution is to do something like adding a --proxy flag:

> node server.js --port 9090
> browserify api.js | smokestack --proxy localhost:9090 | tap-spec

smokestack then proxies all requests other than the piped-in script through to localhost:9090. smokestack could serve the script up on some random, prefixed url to prevent possible collisions with the proxied api, or perhaps even takes the path to serve the script on as an argument.

[timoxley]

This is also important if you have custom build+host process that doesn't pipe the built JS to a terminal.

Maybe if it was as simple as having the script it loads be configurable.

i.e. instead of loading script.js it'll load whatever is passed onto the command line.

> node server.js --port 9090 // serves bundle.js on 9090
> browserify api.js | smokestack --script=http://localhost:9090/bundle.js | tap-spec

This is much more feasible possible now that the instrumentation is loaded separately (/init.js) from the input script (/script.js).

Would still use the default script.js if no script argument supplied.

[timoxley]

Another solution could be to make the instrumentation requirable so I can get the browser console output piped back to the server and set up something smokestack-like programmatically.

[hughsk]

@timoxley I've been trying to do so for a while but haven't been able to get it right. Would you be interested in giving it a shot? :)

[timoxley]

I've been trying to do so for a while

do what?

Would you be interested in giving it a shot? :)

I had a quick look into it. Seems just need to make script.js configurable here: https://github.com/hughsk/smokestack/blob/190cc891d08f17aa7456c0ffa51a59cba1ba9cae/instrument.js#L100

At the moment the bundle is prebuilt. Should just make it build on the fly and swap the var during the build, perhaps using envify?

[hughsk]

Another solution could be to make the instrumentation requirable

Been trying to do that.

At the moment the bundle is prebuilt. Should just make it build on the fly and swap the var during the build, perhaps using envify?

Building it on the fly requires installing browserify alongside smokestack which isn't really ideal. I think even though it's a bit "dirty" a find/replace makes the most sense here, simple and safe :)

[timoxley]

yep, just need to make the script name more unique

[ericelliott]

I'm also very interested in this.