Manual Reference Source Test

Contributing

So you're interested in giving us a hand? That's awesome! We've put together some brief guidelines that should help you get started quickly and easily.

There are lots and lots of ways to get involved, this document covers:

Raising Issues

If you're about to raise an issue because you think that you've found a problem with the application, or you'd like to make a request for a new feature in the codebase, or any other reason… please read this first.

The GitHub issue tracker is the preferred channel for bug reports, feature requests, and pull requests but respect the following restrictions:

Report A Bug

A bug is a demonstrable problem that is caused by the code in the repository. Good bug reports are extremely helpful - thank you!

Guidelines for bug reports:

  1. Use the GitHub issue search — check if the issue has already been reported.
  2. Check if the issue has been fixed — try to reproduce it using the latest master or look for closed issues.
  3. Include a screencast if relevant - Is your issue about a design or front end feature or bug? The most helpful thing in the world is if we can see what you're talking about. Just drop the picture after writing your issue, it'll be uploaded and shown to the developers.
  4. Use the Issue tab on GitHub to start creating a bug report. A good bug report shouldn't leave others needing to chase you up for more information. Be sure to include all the possible required details and the steps to take to reproduce the issue.

Feature Requests

Feature requests are welcome. Before you submit one be sure to:

  1. Use the GitHub Issues search and check the feature hasn't already been requested.
  2. Take a moment to think about whether your idea fits with the scope and aims of the project, or if it might better fit being an app/plugin.
  3. Remember, it's up to you to make a strong case to convince the project's leaders of the merits of this feature. Please provide as much detail and context as possible, this means explaining the use case and why it is likely to be common.
  4. Clearly indicate whether this is a feature request for the application itself, or for packages like Providers, Metadatas, or other.

Pull Requests

Pull requests are awesome. If you're looking to raise a PR for something which doesn't have an open issue, please think carefully about raising an issue which your PR can close, especially if you're fixing a bug. This makes it more likely that there will be enough information available for your PR to be properly tested and merged. To make sure your PR is accepted as quickly as possible, you should be sure to have read all the guidelines on:

Commit Messages

This project uses the Conventional Commits convention. If you are not familiar with this convention please read about it first before creating a commit message or a PR.

Styleguides

JavaScript Styleguide

All JavaScript must adhere to JavaScript Standard Style.

Tests Styleguide

Documentation Styleguide

Setting up for development

To setup your local machine to start working on the project you can follow these steps:

  1. Install NodeJS (at least Node v7.10.1 or greater)
  2. Clone the repository with: git clone https://github.com/popcorn-official/pop-api-scraper.git
  3. Install dependencies npm i
  4. Install the flow-typed libraries with npm run flow-typed

npm scripts

The following npm-scripts are available in order to help you with the development of the project.

 $ npm run build    # Transform the code with 'babel'
 $ npm run docs     # Generate the documentation with 'esdoc'
 $ npm run debug    # Run the applicaiton in debug mode
 $ npm run dev      # Run the application in development mode
 $ npm run flow     # Check flow typings
 $ npm run lint     # Check javascript style
 $ npm run test     # Run unit tests

Git hooks

The following git hooks are available to ensure the changes you are about to make follow the styleguides and make sure your changes pass the tests.

pre-commit          # npm run lint && npm run flow
pre-push            # npm run test