Spectrum chat for Danger

# Announcements

Big words, on major releases

Trending conversations
Request or Approve changes
@d3v · 15d
Support for GitHub Draft PRs
@ioveracker · 28d
Danger running from parent directory in CI
@dfalling · 72d
How to setup running danger as a GitLab CI job?
@daskaja · 109d
Danger in Github Actions
@crosscompile · 36d

Announcing Danger 2.0

November 5, 2017 at 6:58pm

3 months ago I started working on Danger 2.0 in August The aim for 2.0 was to move away from Jest's VM infrastructure in order to simplify integration of Danger into projects that already use Jest, as well as to look into building security tools into Danger so that hosted-Danger (Peril could "safely" evaluate/sandbox arbitrary JavaScript from the internet.) .

It was a pretty small aim, but it would need to be a major version break because I couldnt be certain that the exact same Dangerfile setup would run once I brought a lot of that work into Danger. Danger got a lot of free work from Jest, but my favourite was that Danger got a config-less transpilation setup. Jest also provided a great API for running code inside a sandbox'd environment.

To get started, I first explored vm2 as an option for handling the sandbox, this worked, but had issues with modules that used Proxy, which Babel used in it's regenerator-runtime. This made it real tough to consider for 2.0 as the main way to evaluation JavaScript.

A few weeks after starting work on 2.0, I came to a startling conclusion based on some work I had been doing to improve documentation inside the editor on Danger.SystemsDanger.Systems (if you've not tried it, you should, it's really slick). Danger could be split in two*.

This is what became the key paradigm for what 2.0 represents. A move from Danger being one process to being two processes. Why though? Well, there's a single key reason: Separation of Danger setup + messaging from user-code evaluation.

This is great for everyone because it:

  • Removes the need to schedule any Promise inside Dangerfiles. This is because we're not running JavaScript inside a vm which cannot wait for all ticks to finish. Instead, it's a full instance of a node script whose job is to run the Dangerfile, Danger will wait for the process to terminate which indicates it's time to send the message back to the code-review platform., s
  • Any process can be a Dangerfile runner, so long as you can read from STDIN and post JSON to STDOUT. Here's a trivial Ruby script that acts like a Dangerfile:
#!/usr/bin/env ruby
require 'json'
json = STDIN.tty? ? 'Cannot read from STDIN' : $
danger = JSON.parse(dsl
results = { warnings: [], messages:[], fails: [], markdowns: [] }
if "Hello world"
results.messages << { message: "Hey there" }
require 'json'

Danger JS uses the exact same technique danger will call danger runner under the hood once the DSL is ready. This is meant that other languages can build their own runners, for example Swift and Go It's now a pretty small amount of work to build a new language integration on top of Danger JS. .

This also represents the time towards helping the community help each other, I've been running a private Danger slack for 2 years but it's not really a place to ask questions - it's for implementation questions. So, I've moved to using Spectrum for user support as of 2.0. I'm optimistic that it's indexed by google, and is oriented towards supporting large communities of OSS developers. So if you have questions, ask here :+1:

November 5, 2017 at 7:57pm
  • reply
  • like

So the TL;DR is nothing should change for users, but the entire insides were ripped out to make hosted Danger easier to do?

  • reply
  • like

Yep, a publicly available hosted Danger is now possible and I have done my feasibility testing:

  • reply
  • like