he/him 
@sebmck in Rome, have you abstracted away the 'host environment' in any way to make the toolchain available in contexts like the browser? Certainly would be amazing to have a tight, UX friendly ecosystem like that in the browser.
-
I don’t think that’s a good idea if you want usage from Node.js module authors. We have to run our tests across a range of Node.js versions (2-4 at any given time). Tests frameworks should run across all LTS runtimes without problems.
Of course! If Rome were distributed on npm then it wouldn’t bundle anything. For external distribution it makes more sense. It has a lot of implications, which is why I’ve yet to form a strong opinion. If Rome supports running in a different host which is faster, then makes...
-
-
It would be a nice touch to provide tooling support for future Rome devs (not users) to prevent them from reaching for host-specific APIs. Each plugin that encodes a new host-specific API narrows where the tool can be used. Rome could give tools to devs to stay 'pure'.
-
I've tried to make things pretty lightweight. The current list of Node built-ins that Rome uses are: stream: 8 readline: 2 util: 4 net: 4 child_process: 4 crypto: 4 path: 22 fs: 16 module: 1 zlib: 1 os: 3 inspector: 2
- 1 more reply
New conversation -
-
-
sense to promote it. Any test/code execution though makes it really complicated because it’s host-specific.
-
If you can run it in another machine, I’d distribute it as a docker image.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.