Skip to main content
BEEQ is an open-source design system built by Endava, and contributions from the community are what make it better. Whether you’re fixing a typo, reporting a bug, or building a new component, every contribution matters.

​
What kinds of contributions are welcome?

  • Bug reports — found something broken? Open an issue.
  • Feature requests — have an idea? We’d love to hear it.
  • Code contributions — bug fixes, new components, performance improvements.
  • Documentation — improvements to docs, examples, and guides.
  • Tests — additional unit tests or e2e coverage.

Development Setup

Install dependencies, run the dev server, and build the project locally.

Creating Components

Learn how to scaffold new components using the built-in generator.

Testing

Run unit tests and end-to-end tests with Jest and Puppeteer.

Code Style

Formatting rules, linting configuration, and editor settings.

Commit Messages

How to write conventional commit messages and PR titles.

Changelog

Understand how the changelog is generated from commits.

​
Code of Conduct

BEEQ has adopted the Contributor Covenant as its Code of Conduct. All contributors are expected to adhere to it. Please read the full text in CODE_OF_CONDUCT.md to understand what behavior will and will not be tolerated.

​
License

By contributing to BEEQ, you agree that your contributions will be licensed under the same Apache 2.0 License that covers the project. If you have concerns about this, reach out to the maintainers at [email protected].

​
Reporting bugs

Report a bug by opening a new issue on GitHub. A great bug report includes:
  • A quick summary and/or background description
  • Steps to reproduce (be specific, include sample code if you can)
  • What you expected to happen
  • What actually happens
  • Any notes — why you think this is happening, or what you’ve already tried

​
Pull requests

Pull requests are the best way to propose changes to the codebase. Here’s what we ask:
  1. Fork the repo and branch off from main.
  2. Add unit tests for any new code that should be tested.
  3. Add end-to-end tests for any new component.
  4. Update documentation if you’ve changed an API.
  5. Make sure the test suite passes.
  6. Ensure no new linting violations are introduced.
  7. Submit your pull request.
PR titles must follow the same Conventional Commits format as commit messages. Always use Squash and merge when merging.

​
We develop with GitHub

All code, issue tracking, and pull request reviews happen on GitHub. If you’re new to GitHub’s contribution flow, check out the GitHub Flow guide.

Build docs developers (and LLMs) love

Get started for freeTalk to us