To encourage active collaboration, Lychee strongly encourages pull requests, not just bug reports. "Bug reports" may also be sent in the form of a pull request containing a failing test.
However, if you file a bug report, your issue should contain a title and a clear description of the issue. You should also include as much relevant information as possible to demonstrates the issue. We provide a template and expect it to be respected. Most bug report not following it will likely be closed. The goal of a bug report is to make it easy for yourself - and others - to replicate the bug and develop a fix.
Remember, bug reports are created in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the bug report will automatically see any activity or that others will jump to fix it. Creating a bug report serves to help yourself and others start on the path of fixing the problem. If you want to chip in, you can help out by fixing any bugs listed in our issue trackers.
Lychee's GitHub issue trackers are not intended to provide Lychee help or support. Please instead, contact us directly here on gitter.
Lychee uses a rolling release system, we do not backport fixes to previously released versions. Those are the versions where we accept vulnerability reports.
Version | Supported |
---|---|
master | ✔ |
latest release | ✔ |
< 4.0 | ✕ |
If you discover a security vulnerability within Lychee, please contact us directly on Gitter. All security vulnerabilities will be promptly addressed.
You may propose new features or improvements of existing Lychee behavior in the issue board. If you propose a new feature, please be willing to implement at least some of the code that would be needed to complete the feature.
Pull request need to respect a few simple constraints described below which make the life of everyone easier.
When submitting a new feature or fixing a bug, please create a new branch from master:
git checkout master
git pull master
git checkout -b <fix-issue-number>
Modify the desired files.
git add <files-you-modified>
git commit -m "<mesage-of-what-is-going-on>"
git push -u
You can then open a pull request.
As you may have noticed already we have two repositories to manage separately the front-end and the back-end. This was necessary at times to ensure the parallel development of Lychee version 4 and Lychee version 3. As a result, the process of submitting a PR which modified both sides (Lychee-front and Lychee) goes as follows:
In order to ease the review of pull requests we adopt a uniform code style. Our Continuous Integration suite will fail if the later is not respected.
Our coding style is defined by the .php-ps
file, it is mostly the Symfony style but we use tabs instead of spaces.
Before submitting a PR, we highly encourage you to do:
./vendor/bin/php-cs-fixer fix -v --config=.php-cs-fixer.php
# or
make formatting
This will ensure that the code is consistent with our style.
In order to make this less constraining, you can copy the pre-commit
file in the root into the .git/hooks
folder. This will execute the fixer to keep the consistency.
Our current configuration can be found here. For details about the options you can have a look at the php-cs-fixer-configurator
Similarly to described above, you can format the code automatically with:
npm run format
Below is an example of a valid Laravel documentation block. Note that the @param attribute is followed by two spaces, the argument type, two more spaces, and finally the variable name:
/**
* Register a binding with the container.
*
* @param string|array $abstract
* @param \Closure|string|null $concrete
* @param bool $shared
* @return void
*
* @throws \Exception
*/
public function bind($abstract, $concrete = null, $shared = false)
{
//
}
In addition to code documentation, we highly encourage you to use the types system of php for the function arguments. This will increase the trust and safety of the code.
As follows we present a simple pull request modifying the readme.md
.
LycheeOrg
on the branch master
.The Lychee code of conduct is the same as Laravel's code of conduct:
{tip} Caught a mistake or want to contribute to the documentation? Edit this page on Github!