danger / generator-danger-plugin

Yeoman generator to generate a Danger plugin

Danger 🚫

Formalize your Pull Request etiquette.

---

What is Danger? • Vision • Helping Out • Plugin Development

---

What is Danger?

Danger runs during your CI process, and gives teams the chance to automate common code review chores.

This provides another logical step in your process, through this Danger can help lint your rote tasks in daily code review.

You can use Danger to codify your teams norms. Leaving humans to think about harder problems.

For example?

You can:

• Enforce CHANGELOGs
• Enforce links to Trello/JIRA in PR/MR bodies
• Enforce using descriptive labels
• Look out for common anti-patterns
• Highlight interesting build artifacts
• Give specific files extra focus

Danger provides the glue to let you build out the rules specific to your team's culture, offering useful metadata and a comprehensive plugin system to share common issues.

Getting Started

Alright. So, actually, you may be in the wrong place. From here on in, this README is going to be for people who are interested in working on and improving on Danger.

We keep all of the end-user documentation at https://danger.systems.

Some quick links: Guides Index, DSL Reference, Getting Started and What does Danger Do?.

I'm here to help out!

Brilliant. So, let's get you set up.

git clone https://github.com/danger/danger.git
cd danger
bundle install
bundle exec rake spec

This sets everything up and runs all of the tests.

Theory

Danger has a VISION.md file, which sums up the ideas around what Danger is. It is the lower bounds of what Danger means. Orta has written on handling and creating Danger on the Artsy blog, too.

Documentation

The code you write may end up in the public part of the website — the easiest way to tell is that it is vastly overdocumented. If you are working in a space that looks over-documented, please be extra considerate to add documentation. We expect the consumers of that documentation to be non-rubyists, thus you should avoid specific jargon and try to provide duplicate overlapping examples.

Testing

So far, we've not really figured out the right way to make tests for our CLI commands. When we have done so, they've ended up being brittle. So, ideally, try to move any logic that would go into a command into separate classes, and test those. We're okay with the command not having coverage, but ideally the classes that make up what it does will.

I'd strongly recommend using bundle exec guard to run your tests as you work. Any changes you make in the lib, or specs will have corresponding tests run instantly.

Debugging

Ruby is super dynamic. One of the best ways to debug Ruby code is by using pry. We include pry for developers: when you have a problem, copy these two lines just before your problem and follow the instructions from "I Want To Be A Danger Wizard."

require 'pry'
binding.pry

License, Contributor's Guidelines and Code of Conduct

We try to keep as much discussion as possible in GitHub issues, but also have a pretty inactive Slack --- if you'd like an invite, ping @Orta a DM on Twitter with your email. It's mostly interesting if you want to stay on top of Danger without all the emails from GitHub.

This project is open source under the MIT license, which means you have full access to the source code and can modify it to fit your own needs.

This project subscribes to the Moya Contributors Guidelines which TLDR: means we give out push access easily and often.

Contributors subscribe to the Contributor Code of Conduct based on the Contributor Covenant version 1.3.0.

generator-danger-plugin's Issues

Action required: Greenkeeper could not be activated 🚨

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

Make semantic-release an option

This generator is pretty specific to my personal workflow, so it might be nice to make semantic-release integration an option.

As part of this option, though, it would be cool that once all dependencies are installed, the generator will cd into the newly created directory and run semantic-release-cli setup as the final step.

Offer to install semantic-release-cli

Fix creation script, update release script and upgrade dependencies

Hi, I'm trying to create a new Danger JS plugin, but when running this generator, I get this error at the end:

events.js:183
      throw er; // Unhandled 'error' event
      ^

Error: write after end
    at writeAfterEnd (_stream_writable.js:236:12)
    at Transform.Writable.write (_stream_writable.js:287:5)

Files and folders are created, but maybe something will be missing?

Might be due to something wrong in my local environment (I'm running node 8.11.2 and npm 5.10.0), but I noticed the project hasn't been updated for a long time, so maybe it's due to being a bit outdated 😅

Also, after running npm install (I've selected to build the npm version without TypeScript) I get this warnings:

npm WARN prepublish-on-install As of npm@5, `prepublish` scripts are deprecated.
npm WARN prepublish-on-install Use `prepare` for build steps and `prepublishOnly` for upload-only.
npm WARN prepublish-on-install See the deprecation note in `npm help scripts` for more information.

Finally, I've also seen that the dependencies installed are a bit outdated, so it would be nice to upgrade to the latest versions :-P

Could you look into those issues? 😇

Many thanks,
Sogame

Publish package from dangersystems npm account

Right now, each fix or feat commit merged to master will ship a new version of this plugin (per semantic-release). The npm package is published under my name. I've added dangersystems and orta as collaborators, though.

@orta is there anything we should do to change ownership on npm? Do we just need to swap my NPM_TOKEN in the Travis build settings with dangersystems NPM_TOKEN, or is this dangerous territory?

Allow option to choose JavaScript and TypeScript

What if I want to write a Danger plugin in TypeScript and not JS (Babel)? It would be cool to support that. 👍

Action required: Greenkeeper could not be activated 🚨

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

cd into new plugin folder at the end of the process

Add Dangerfile

• Setup Travis with a DANGER_GITHUB_API_TOKEN used in the danger/danger-js repository
• Create a simple Dangerfile (TypeScript preferably ❤️)
  • The Dangerfile should validate each commit message, similar to how RxJs does it
• Update .travis.yml to include yarn run danger

new project with typescript includes JS for index.ts

init git repo?

We do this in https://github.com/artsy/yeoman-generator-artsy

Add code documentation

Since this is open-sourced (and also for future me who will likely forget how things work 😅 ), it would be nice to add ESDoc for files in the repo while it's still fresh in my mind.

Add option to add keywords

Each Danger plugin has "danger" and "danger-plugin" as keywords in package.json. It would be nice to give the user an option to add more keywords.

In order to do this:

• read the template package.json
• use something like deep-extend or _.assignIn to concat user-supplied keywords
• write the new package.json file to the destination path

Illogical sentence

Pretty sure I choose the name danger-yarn which I think this interpreted to be a case of you must have "danger-plugin" in your name.

Your generator must be inside a folder named danger-plugin-danger-yarn