Thank you for contributing to Ziglite !
Contributions are welcome and will be properly credited.
Please read this contribution guide carefully and follow the outlined guidelines before opening an issue or creating a pull request.
If you need any help with any of this documents guidelines, please do not hesitate to ask.
We ask that you :
- Be civil, Be kind.
- Give people the benefit of doubt and assume good intentions by default.
Harassement will not be tolerated. Thank you.
While feature requests are always welcome, please consider the scope of the project first.
Ziglite's raison d'être is to be a simple alternative to Ziggy. If you need more advanced features, please consider using Ziggy.
If you still would like to submit a feature request, please open an issue and select Feature request.
Before sending a bug report, please:
- Check if an issue has not already been opened for the same bug
- Check if a pull request has not already been opened for the same bug
If you still would like to submit a bug report, please open an issue and select Bug report, then thoroughly fill the form.
Please include a minimal reproducible example to avoid your issue being closed.
To get started with contributing code, please:
- Fork the repo
- Clone your fork locally
- Run
composer install
to install PHP dependencies - Run
yarn
to install javascript dependencies - Run
yarn prepare
to setup your Husky 🐶 woof!
Before opening a pull request, please check if a pull request has not already been opened for the same changes. If you would like to submit multiple features or bug fixes, please submit a pull request for each.
Your pull request must also include tests for all the changes you're submitting.
We use Pest with Orchestra Testbench to test PHP code, and Vitest to test javascript code.
- Run PHP tests using
vendor/bin/pest
oryarn test:php
- Run javascript tests using
yarn test
- To run all tests, use
yarn test:all
To release a new version of Ziglite:
- Update the version string in PackageService
- Update the package version field using yarn version
- Update the Changelog (following the keep a changelog format)
- Rebuild the assets
yarn run build
- Commit and push the changes to the appropriate branch.
- Publish a new release on Github
- Make sure you create a tag targetting the right branch
- Make sure the name is the correct version prefixed with
v
The npm.yaml workflow will then be triggered to publish the NPM package.
Use an appropriate suffix (i.e. -beta
in the branch name and version) and mark the GitHub release as a pre-release when creating a beta, RC, or pre-release.
This will publish the NPM package unde the next
tag.