Proposal: Support Dangerfile.js

[orta]

Conceptually the Dangerfile is in Ruby because everything else is in Ruby, it makes for something that is easy to eval and inject your own code, and we have lots of history to work with. It's a solid mature language.

What if we also supported the most popular programming language.

In theory we would need to be able to expose any Danger::Plugin as a global javascript object in the scope. This can be done via something like ruby_ffi-javascriptcore or commonjs.rb then we eval the Dangerfile.js and it has all the same powers as the Dangerfile.

Three main advantages:

1. More people can read/write Dangerfiles
2. Could in theory also support node modules as danger plugins
3. With effective sandboxing, it may be possible to look deeper into danger as a service

[orta]

an example of issue 1 - bnb/awesome-hyper#68

[orta]

Danger can probably run Python code to with this: http://rubypython.rubyforge.org

[orta]

This kind of thing makes me wish there were subspecs for rubygems, rubypython support would add 3 dependencies

[orta]

Looks like I can use this pattern: http://www.visuality.pl/posts/handling-optional-dependencies-in-gems

And then in the docs, we can say you need to have both danger and rubypython installed in order to have python Dangerfiles.

[samdmarshall]

would we be able to write the dangerfile completely in JavaScript or Python or whatever language, or would it require we add the boilerplate code to get it to be handled by ruby?

[orta]

For the JS Dangerfile, it would be completely in JS, I'd expose all of the ruby objects and their public methods to the JS runtime before the Dangerfile.js is eval'd and you should be able to write the exact same kind of Dangerfile but in JS.

For other environments it's harder to say outright without research - I looked at rubypython but I'm not sure that I can expose Danger plugins to the python parser

There is no support for passing complicated (non-basic) Ruby types to Python.

[samdmarshall]

Hmmm, I wonder if it might not be better to write a C library that uses the Ruby and Python FFI interfaces to transfer things across then. I don't know enough about Ruby to do that myself though. I took a quick look at the rubypython interface and it feel that it seems a bit overly complicated to feel like it is worth supporting vs the javascript implementation being "pure". Something I thought about a lot when designing the pyconfig DSL was how close to Python I wanted to keep it -- if it might be worth looking changing Danger to be less of a ruby-subset and more of a DSL?

[orta]

That one is tough, I genuinely don't know the answer here. I want to avoid native modules. Mainly because that raises the barrier of entry to other contributors, and can make it harder for others to install Danger. Danger has already had to change git libraries twice because of native modules not building on vanilla macs.

My priorities for this is JS, and then everything else, realistically. I'm starting to write a lot more JS in day-to-day, and the majority of OSS code is JS nowadays.

I'm happy to continue digging for ways to allow other languages to work with Danger, but if we can only send over the basic types then I'd have to make the DSLs considerably more comprehensive - which I want to avoid if I can.

[orta]

Current thoughts: I sit somewhere between just wanting to ship this and mark it as experimental - and saying that this is worth making relatively drastic API changes ( allowing Danger to communicate to the Dangerfile runner across processes.)

It's probably worth having this but being "that be dragons here" hands-off-y. I think any real integration with JS has to include node, and to include node we have to do something different than the current implementation.

Last time I whined about it online.

[orta]

This idea failed in Ruby, and now it's got a semi-working re-write in JS. Closing.