Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
60 lines (42 loc) · 2.91 KB

CONTRIBUTING.md

File metadata and controls

60 lines (42 loc) · 2.91 KB

Contributing to angular-pdf

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

for fixes

  1. This is for a fix or a patch for a found bug

  • Fork this project and install the packages with npm

    npm install

  • Install peer dependencies with npm

    npm install angular pdfjs-dist

  • Create a new patch branch

  • Code code code and amend the file src/angular-pdf.js

  • Run npm run start to start the webpack-dev-server and open http://localhost:8080

  • Code code code

  • Run npm test to ensure the build and the tests will pass

  • update readme.md if required, especially the section on Features

  • Ensure that you are not committing files contained in dist folder (builds are for mantainers' exclusive)

  • Write a good commit message

  • Pull request using the new patch branch

  • Ensure the Travis build and tests passes

for new features

  1. Search 🔎 if the feature already exists or was discussed previously in closed issues
  • Raise an issue to discuss 💬 , ask for feedback or help 💭
  • Ensure the pull request is accompanied by new feature code and specs / tests ( similar to submitting fixes )

##Make a Release (for maintainers only)

  1. run npm run release patch, npm run release minor or npm run release major according semantic version
  • done 🎉

npm run release also update gh-pages then you don't need to update manually

##Angular-PDF is an OPEN Open Source Project

☀️ Read more about the OPEN Open Source Project ☀️

Individuals making significant and valuable contributions are given commit-access to the project to contribute as they see fit. This project is more like an open wiki than a standard guarded open source project.

Rules

There are a few basic ground-rules for contributors:

  1. No --force pushes or modifying the Git history in any way.
  2. Non-master branches ought to be used for ongoing work.
  3. External API changes and significant modifications ought to be subject to an internal pull-request to solicit feedback from other contributors.
  4. Internal pull-requests to solicit feedback are encouraged for any other non-trivial contribution but left to the discretion of the contributor.
  5. Contributors should attempt to adhere to the prevailing code-style.

Releases

Declaring formal releases remains the prerogative of the project maintainer.