Contributing Code (Symfony Docs)

There are many ways to contribute to the Symfony code, listed here from the quickest to the most involved: reporting a bug you found, fixing a bug, or adding a new feature. This guide covers all of them.
Prefer video? Check out the Contributing Back To Symfony screencast series.
The simplest way to contribute is to report a bug you found. It helps us make Symfony better even if you don't fix it yourself.
If you think you've found a security issue, don't report it publicly. Follow the security procedure instead.
This is about bugs. If you have an idea for a new feature, discuss it first on the #contribs channel of the Symfony Slack or open an issue (ideally alongside a pull request) rather than just filing a request.
Report the bug on the official issue tracker following these rules:
A bug reproducer is the minimum amount of code needed to trigger the bug. It makes the difference between a bug that's fixed quickly and one that can't be understood.
For a component used outside the framework, a small PHP script is enough:
For a bug in the framework, create a minimal project, push it to a new GitHub repository and link it in your issue:
The key is to add only the code needed to reproduce the bug: don't copy your whole application. Start from the feature you suspect (a route, a service, an event listener...), add the smallest possible code that shows the bug, and use the Symfony CLI (symfony server:start) to check it. Keep adding small changes until the bug appears.
A stack trace shows the trail of function calls that led to an exception. When reporting an exception, always include the plain text stack trace.
When reading a stack trace, focus first on the lines under src/ (your code) rather than vendor/, since third-party code is less likely to be the source of the bug. If several exceptions are shown, the most relevant one is usually the first (exception [1/n]). Report the bug to the library that throws it (for Symfony components, use composer home symfony/symfony, which opens the package's repository URL or homepage in your browser).
Symfony's exception page provides the Stack Trace in plain text, ready to paste into a bug report (remember to remove sensitive data):
Commands only show the exception message by default. Add --verbose to get the full stack trace:
When the response isn't suitable for sharing, open the profiler to get a plain text trace. Its URL is in the X-Debug-Token-Link response header:
To fix a bug or work on a feature, set up a local copy of Symfony. You only need to do this once.
Install Git and PHP 8.2 or higher. Then set your name and email in Git (they appear in your commits):
On Windows, make sure Git doesn't rewrite line endings when cloning: git config --global core.autocrlf input.
Clone your fork locally (this creates a symfony/ directory):
Add the original repository as a remote called upstream. You'll use it to keep your fork up to date:
Now check that everything works by running the test suite.
To try your Symfony changes inside an existing project, use the link script included in the repository. It replaces the Symfony packages in your project's vendor/ directory with symbolic links to your local Symfony clone:
Make sure the project's dependencies are installed (composer install) before running it. Use --copy if your environment can't resolve symlinks, and --rollback to restore the original dependencies when you're done.
New features target the current development branch instead of 6.4.
A pull request (PR) is the way to send a bug fix or a new feature to Symfony.
Before working on a change, search the existing issues and pull requests to see if someone already reported the topic or started a PR. If you have any questions during the process, ask on the #contribs channel of the Symfony Slack.
All the code you contribute must be released under the MIT license.
Which branch should I use? Base your pull request on the right branch so it can be merged without extra work:
You only pick the branch once, when creating your topic branch. Everything else in this guide works the same regardless of the branch you chose.
Create a topic branch off the branch you chose. Use a descriptive name (fix_XXX, where XXX is the issue number, is a good convention for bug fixes):
Work on the code and commit as much as you want, keeping these rules in mind:
Write good commit messages. Start with a short subject line: the affected component, bridge or bundle in square brackets, then a capitalized, imperative sentence with no trailing period. Add a blank line and a longer description if needed. For example:
If your change is a new feature or changes existing behavior, also update:
Update your branch with the latest changes from upstream and resolve any conflict (replace 6.4 with the branch you chose):
Then push your branch to your fork:
Now open a pull request on the symfony/symfony repository, targeting the branch you chose (e.g. 6.4). The PR description contains a table you must fill in; some answers add requirements:
Give as much detail as possible in the description: it helps the review and becomes part of the permanent record when the PR is merged. If the code isn't finished yet, open the PR as a draft so reviewers know it's still in progress.
We ask all contributors to follow some review best practices to keep feedback constructive. The core team decides which PRs get merged, so their feedback is the most relevant. Don't feel pressured to apply every suggestion immediately. If you receive feedback you find abusive, contact the CARE team.
When you open a PR, several automated checks run on GitHub Actions:
To apply review feedback, commit your changes on the same branch, rebase on the latest upstream branch (don't merge) and force-push: