VISION.md
Danger JS is a tool for creating complex per-project rules, and messages in Code Review. One of its key aims is to be able to run on a server, and not need direct access to the filesystem to do its work.
It was started in mid-2016 and has fleshed out into a considerable set of useful tools.
danger init.danger ci.danger pr.danger local.Wow, hi... So it's mid-2019. Three years in, 9 major versions, 150+ releases and every major long-term goal for Danger JS has been accomplished:
So, what now? Well. It's kinda done and now can mature. For the past few years Danger Ruby has solidified and become foundational infrastructure which you can trust won't change much, now Danger JS can be in the same place. This is a great place to be for a developer tool.
When I started Danger JS, Danger Ruby was two years old, is still doing just fine. See the original vision file. This document assumes you have read it.
The amount of issues we get in comparison to the number of downloads on Rubygems makes me feel pretty confident about Danger Ruby's state of production quality and maturity. I wanted to start thinking about the larger patterns in software because at Artsy, we are starting to use JavaScript in for many teams.
I've explored running JavaScript from the ruby Danger,
(example from
production) but this pattern isn't going to work on the larger scale: You cannot use npm modules, nor work with
babel/tsc to transpile your Dangerfile.js and the requirements on the integrating project
feel weird. Running JS in Ruby isn't going to work for me.
This realization came at the same time as serious thinking on a hosted version of Danger. With a JavaScript version, we can limit the exposed Danger DSL to only something that can be obtained over the API remotely. By doing this, a hosted Danger does not need to clone and run the associated projects. This is essential for my sanity. I cannot run multiple servers like CocoaDocs. So far, I'm calling this Peril. You can consult the vision file for Peril if you'd like.