Release 0.4 Second Week

First failed PR!

Second week into Release 0.4 I was decided to take on the task of trying to implement danger js.

First, let us talk about the situation, a lot of contributors in the class were having issues with their package and package-lock files. The usual process would usually be like this

1. update master to current upstream with git pull upstream master
2. enter npm install to install all dependencies for libraries being used

Seems like this was a problem for a lot of people, whenever they pulled, they usually forget to update their package-lock with npm install. Afterwards, when contributors try to submit their PRs, our CIs' (Travis + Circle) complain something is off with the contributor's package-lock.

To combat this, the professor suggested we trying implementing a library called danger js. It is a library that allows users to set warnings that can also be used by the CI services to inform users making a pull request about the status of their files. We were interested in two use cases:

• reminding users if their package.json file has changed but their package-lock.json file has not
• reminding users if any of the src files have been changed, but tests for the changed src files have not been modified

The first one would always remind users to do an npm install so their package-lock.json is synchronized with the one on master assuming they did not install new libraries to the project

The second one would always remind users, if any of the source files have been changed, maybe they should update or write new tests to accommodate the changed code.

The process is pretty easy, users create a file called dangerfile.js and write what conditions they want to check to trigger messages to be displayed. An example is displayed below.

const apps = includes(danger.git.fileMatchc, '../*.js');

const tests = includes(danger.git.fileMatch, '../../test/*.test.js');

if (apps.modified && !tests.modified) {
  const message = `Changes were made to file in src, but not to the test file folder`;
  const idea = `Perhaps check if tests for the src file needs to be changed?`;
  warn(`${message} - <i>${idea}</i>`);
}

After preparing a danger file, the next step is to integrate it with a CI service, the website for the library has specific instructions depending on the CI service... this is where things get kind of dicey and where the professor decided against implementing this library.

To be able to integrate with Github, users have to generate their own Github API token and add it to their CI service, that isn't too bad. What is bad though is in order for danger js to work with the CI, users also have to enable an option displaying the API token in the build log, this is dangerous as the Github API token is private for every account, publicly displaying this token is pretty bad as that token uniquely identifies an account.

In popular practice this isn't so bad, because a bot is usually used to implement danger js and publicly displaying the bot's token wouldn't have too much of a negative effect (it is a bot). But the thought of having to set up and maintain a bot was too much work, and the alternative to not using a bot would require every user to set their own token in the CI services. With all these requirements needed to get the danger js service working, the professor decided we should not move ahead with this idea.