| 1 | # Danger for JS
|
| 2 |
|
| 3 | Danger JS is a tool for creating complex per-project rules, and messages in Code Review. One of its key aims is to be
|
| 4 | able to run on a server, and not need direct access to the filesystem to do its work.
|
| 5 |
|
| 6 | It was started in mid-2016 and has fleshed out into a considerable set of useful tools.
|
| 7 |
|
| 8 | - You can get started in a fun way via `danger init`.
|
| 9 | - You can run danger via `danger ci`.
|
| 10 | - You can fake running on CI locally for any GitHub PR with `danger pr`.
|
| 11 | - You can run Danger rules inside git hooks, or without pull requests metadata via `danger local`.
|
| 12 | - You can share code using [danger plugins][plugins].
|
| 13 | - Danger can run independently of CI via Peril.
|
| 14 |
|
| 15 | ## Future Plans
|
| 16 |
|
| 17 | Wow, hi... So it's mid-2019. Three years in, 9 major versions, 150+ releases and every major long-term goal for Danger
|
| 18 | JS has been accomplished:
|
| 19 |
|
| 20 | - Support hosted-infra like [Peril](https://github.com/danger/peril)
|
| 21 | - Support custom language runtimes like [Swift](https://danger.systems/swift/),
|
| 22 | [Kotlin](https://github.com/danger/kotlin/) and [Rust](https://github.com/danger/rust)
|
| 23 | - Support GitHub, GitLab and BitBucket Cloud which covers most PR review tools
|
| 24 | - Allow running just with a local set of git commits
|
| 25 | - Documented at scale
|
| 26 |
|
| 27 | So, what now? Well. It's kinda done and now can mature. For the past few years Danger Ruby has solidified and become
|
| 28 | foundational infrastructure which you can trust won't change much, now Danger JS can be in the same place. This is a
|
| 29 | great place to be a developer tool.
|
| 30 |
|
| 31 | # Why Danger JS? What about Danger Ruby?
|
| 32 |
|
| 33 | When I started Danger JS, Danger Ruby was two years old, is still doing just fine. See the
|
| 34 | [original vision file](https://github.com/danger/danger/blob/master/VISION.md). This document assumes you have read it.
|
| 35 |
|
| 36 | The amount of issues we get in comparison to the number of downloads on Rubygems makes me feel pretty confident about
|
| 37 | Danger Ruby's state of production quality and maturity. I wanted to start thinking about the larger patterns in
|
| 38 | software because at Artsy, we are starting to use JavaScript in
|
| 39 | [for many teams](http://artsy.github.io/blog/2016/08/15/React-Native-at-Artsy/).
|
| 40 |
|
| 41 | I've explored [running JavaScript](https://github.com/danger/danger/pull/423) from the ruby Danger,
|
| 42 | ([example](https://github.com/artsy/emission/blob/d58b3d57bf41100e3cce3c2c1b1c4d6c19581a68/Dangerfile.js) from
|
| 43 | production) but this pattern isn't going to work on the larger scale: You cannot use npm modules, nor work with
|
| 44 | babel/tsc to transpile your `Dangerfile.js` and the requirements on the integrating project
|
| 45 | [feel weird](https://github.com/artsy/emission/pull/233). Running JS in Ruby isn't going to work for me.
|
| 46 |
|
| 47 | This realization came at the same time as serious thinking on a hosted version of Danger. With a JavaScript version, we
|
| 48 | can limit the exposed Danger DSL to only something that can be obtained over the API remotely. By doing this, a hosted
|
| 49 | Danger does not need to clone and run the associated projects. This is essential for my sanity. I cannot run multiple
|
| 50 | [servers like CocoaDocs](http://cocoadocs.org). So far, I'm calling this Peril. You can consult the
|
| 51 | [vision file for Peril](https://github.com/danger/peril/blob/master/VISION.md) if you'd like.
|
| 52 |
|
| 53 | [plugins]: https://www.npmjs.com/search?q=keywords:danger-plugin&page=1&ranking=optimal
|
| 54 | [peril]: http://artsy.github.io/blog/2017/09/04/Introducing-Peril/
|