Gherkin is an open source, community-driven project. If you'd like to contribute, feel free to do this, but remember to follow this few simple rules:
- Make your feature addition or bug fix,
- Always use the
masterbranch as base for your changes (all new development happens inmaster), - Add tests for those changes (please look into
tests/folder for some examples). This is important so we don't break it in a future version unintentionally, - Commit your code, but do not mess with
CHANGELOG.md, - Remember: when you create a Pull Request, always select
masterbranch as target (done by default), otherwise it will be closed.
This project uses files from the official cucumber/gherkin monorepo as a development dependency. We use these to keep our translations in sync, and to test that the parser behaviour is consistent (with a few defined exceptions) with the official Gherkin specifications and examples.
We use composer to track and install this dependency by defining it using a custom repository in composer.json. We name
this cucumber/gherkin-monorepo to avoid confusion with the existing cucumber/gherkin PHP package on packagist (which
is a subtree split of the monorepo, and does not contain the test data files we need).
This dependency is maintained and updated by our Github Actions and build scripts, so you should not usually need to pay it much attention.
Make sure that you don't break anything with your changes by running:
composer testWe use automated tools to ensure that the code has a consistent style and is of good quality.
composer lintSome problems detected by the linting tools can be fixed automatically. Simply run the following:
composer fixGherkin supports →40 different languages and you could add more! You might notice i18n.php file in the root of
the library. This file is downloaded and autogenerated from
original cucumber/gherkin translations.
So, in order to fix/update/add some translation, you should send a Pull Request to the cucumber/gherkin repository.
Behat\Gherkin will re-download/regenerate translations from there before each release.
It might sound difficult, but this way of dictionary-sharing gives us the ability to migrate *.feature files from
language to language and library to library without the need to rewrite/modify them - with the same (Gherkin) dictionary
used everywhere.