Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
77 lines (59 loc) · 3.15 KB

CONTRIBUTING.md

File metadata and controls

77 lines (59 loc) · 3.15 KB
Raw

Contributing to Buefy

Thanks for taking the time to contribute! This guide applies org-wide to every repository under the buefy organization. An individual repository may extend or override these guidelines with its own CONTRIBUTING.md.

Before you start

  • Search existing issues and discussions to avoid duplicates.
  • For anything beyond a small fix, open an issue first to discuss the approach before writing code.
  • Read the Code of Conduct — participation in this project means agreeing to abide by it.
  • Never report a security vulnerability as a public issue — see SECURITY.md.

Development workflow

Repositories in this org are trunk-based: main is always releasable, there is no long-lived develop branch, and releases are cut automatically by semantic-release from main on every merge. This means:

  1. Fork the repository and create a branch off main.
  2. Make your change, including tests and documentation updates.
  3. Run the local checks the repository's CI also runs (lint, typecheck, test, build) before opening a pull request.
  4. Open a pull request against main using the repository's PR template.
  5. Once merged, semantic-release computes the next version, publishes to npm, and generates release notes automatically — you do not need to bump version numbers or hand-edit a changelog.

Commit messages

All commits must follow Conventional Commits. The commit message (or, for squash-merged PRs, the PR title) is the source of truth semantic-release uses to compute the next version and changelog entry:

Type Effect
fix: patch release
feat: minor release
feat!: / BREAKING CHANGE: footer major release
docs:, chore:, refactor:, perf:, test:, ci: no release (unless combined with the above)

Examples:

fix(dropdown): close on outside click when teleported
feat(datepicker): add `min-date` prop

BREAKING CHANGE: `disabled-dates` no longer accepts a function; use `min-date`/`max-date`.

Pull requests

  • Keep PRs focused on a single change; unrelated cleanup belongs in its own PR.
  • Fill out the PR template completely, including the type-of-change checklist.
  • Add or update tests for any behavior change.
  • Update component documentation when public props/events/slots change.
  • A CODEOWNERS review is required before merge; CI (lint, typecheck, test, build) must be green.

Adding a new component (component-library repos)

Downstream component-library repos ship a component-scaffolder Claude Code agent and a scaffold-component skill (see that repo's starter-kit-derived .claude/ config) that generate the SFC, unit test, and docs page for a new component from a short spec — use it as the starting point rather than copy-pasting an existing component by hand.

Getting help

See SUPPORT.md for where to ask questions versus where to file bugs.