Skip to content

Latest commit

 

History

History
43 lines (33 loc) · 2.65 KB

CONTRIBUTING.md

File metadata and controls

43 lines (33 loc) · 2.65 KB

Contributions Are Welcome!

If you need any help, don't hesitate to ask the community on Gitter.

Quick Guide

  • Fork the repo.
  • Checkout the branch you want to make changes on:
    • If you are fixing a bug or typo, improving tests or for any small tweak: the lowest branch where the changes can be applied. Once your Pull Request is accepted, the changes will get merged up to highest branches.
    • master in other cases (new feature, deprecation, or backwards compatibility breaking changes). Note that most of the time, master represents the next minor release of PHP CS Fixer, so Pull Requests that break backwards compatibility might be postponed.
  • Install dependencies: composer install.
  • Create a new branch, e.g. feature-foo or bugfix-bar.
  • Make changes.
  • If you are adding functionality or fixing a bug - add a test! Prefer adding new test cases over modifying existing ones.
  • Make sure there is no trailing spaces in code: ./check_trailing_spaces.sh.
  • Regenerate README: php php-cs-fixer readme > README.rst (Windows php.exe php-cs-fixer readme > README.rst). Do not modify README.rst manually!
  • Install dev tools: dev-tools/install.sh
  • Run static analysis using PHPStan: php -d memory_limit=256M dev-tools/vendor/bin/phpstan analyse
  • Check if tests pass: vendor/bin/phpunit.
  • Fix project itself: php php-cs-fixer fix.

Opening a Pull Request

You can do some things to increase the chance that your Pull Request is accepted the first time:

  • Submit one Pull Request per fix or feature.
  • If your changes are not up to date, rebase your branch onto the parent branch.
  • Follow the conventions used in the project.
  • Remember about tests and documentation.
  • Don't bump version.

Making New Fixers

There is a cookbook with basic instructions on how to build a new fixer. Consider reading it before opening a PR.

Project's Standards