Contributions are welcome. This project accepts pull requests on GitHub.
This project adheres to a code of conduct. By participating in this project and its community, you are expected to uphold this code.
You can find help and discussion in the following places:
- GitHub Issues: https://github.com/ramsey/composer-install/issues
Bugs are tracked in the project's issue tracker.
When submitting a bug report, please include enough information to reproduce the bug. A good bug report includes the following sections:
- Expected outcome
- Actual outcome
- Steps to reproduce, including sample code
- Any other information that will help debug and reproduce the issue, including stack traces, system/environment information, and screenshots
Please do not include passwords or any personally identifiable information in your bug report and sample code.
This project welcomes pull requests to fix bugs!
If you see a bug report that you'd like to fix, please feel free to do so. Following the directions and guidelines described in the "Adding New Features" section below, you may create bugfix branches and send pull requests.
If you have an idea for a new feature, it's a good idea to check out the issues or active pull requests first to see if the feature is already being worked on. If not, feel free to submit an issue first, asking whether the feature is beneficial to the project. This will save you from doing a lot of development work only to have your feature rejected. We don't enjoy rejecting your hard work, but some features don't fit with the goals of the project.
When you do begin working on your feature, here are some guidelines to consider:
- Your pull request description should clearly detail the changes you have made. We will use this description to update the CHANGELOG. If there is no description or it does not adequately describe your feature, we may ask you to update the description.
- Please write tests for any new features you add.
- Please ensure that tests pass before submitting your pull request. ramsey/composer-install has GitHub Actions automatically running tests for pull requests. However, running the tests locally will help save time.
- Use topic/feature branches. Please do not ask to pull from your master
branch.
- For more information, see "Understanding the GitHub flow."
- Submit one feature per pull request. If you have multiple features you wish to submit, please break them up into separate pull requests.
- Write good commit messages. Make sure each individual commit in your pull
request is meaningful. If you had to make multiple intermediate commits while
developing, please squash them before submitting.
- For more information, see "How to Write a Git Commit Message."
This project includes a suite of tests located in tests/expect/
.
These tests use the Expect tool to
automate CLI interactions. The tests will run automatically as part of
continuous integration, or you may run them locally with:
composer test
To run the tests, you must have an up-to-date version of coreutils (8.30 or later).
To generate a new test:
cd tests/expect/
autoexpect ../../bin/path-to-script-to-test.sh
autoexpect
will save the test to script.exp
. Rename it with a more
descriptive name, and run it to ensure it does what you expect: ./script.exp
.
You may need to edit the test file or add to it, according to your needs.
When done, cd ../..
and run composer test
.
Your new test should run along with the other tests.