* ci: change package name and release first alpha * chore: change package name
4.6 KiB
Contributing to @supabase/server
Thank you for your interest in contributing to @supabase/server! This document provides guidelines and instructions for contributing to the project.
Table of Contents
- Getting Started
- Development Setup
- Project Structure
- Development Workflow
- Testing
- Code Style
- Submitting Changes
- Release Process
Getting Started
TBD
Development Setup
Prerequisites
- Node.js: 20.x or higher
- pnpm
Installation
- Fork and clone the repository:
git clone https://github.com/YOUR_USERNAME/edge-functions.git
cd edge-functions
- Install dependencies:
pnpm install
- Build the project to verify setup:
pnpm build
Development Workflow
Building
Build the library for distribution:
pnpm build
Watch mode for development (rebuilds on file changes):
pnpm run dev
Formatting
Format all code using Prettier:
pnpm format
Submitting Changes
Commit Messages
We use Conventional Commits for automated releases. Format:
<type>(<scope>): <description>
[optional body]
[optional footer]
Types:
feat: New feature (triggers minor version bump)fix: Bug fix (triggers patch version bump)docs: Documentation changes onlytest: Adding or updating testschore: Maintenance tasks, dependency updatesrefactor: Code changes that neither fix bugs nor add featuresperf: Performance improvementsci: CI/CD configuration changes
Breaking changes:
- Use
feat!:orfix!:for breaking changes (triggers major version bump) - Or include
BREAKING CHANGE:in the commit footer
Examples:
feat: add support for view operations
fix: handle empty namespace list correctly
docs: update README with new examples
test: add integration tests for table updates
feat!: change auth config structure
BREAKING CHANGE: auth configuration now uses a discriminated union
Pull Request Process
-
Create a branch from
main:git checkout -b feat/my-feature -
Make your changes following the guidelines above
-
Commit using conventional commit format:
git commit -m "feat: add support for XYZ" -
Push to your fork:
git push origin feat/my-feature -
Open a Pull Request with:
- Clear title following conventional commit format
- Description of what changed and why
- Reference any related issues (e.g., "Fixes #123")
- Screenshots/examples if adding user-facing features
-
Respond to feedback - maintainers may request changes
PR Guidelines
- Keep PRs focused - one feature or fix per PR
- Update documentation if you change public APIs
- Add tests for new functionality
- Ensure all CI checks pass
- Rebase on
mainif needed to resolve conflicts - Be responsive to review feedback
Release Process
This project uses release-please for automated releases. You don't need to manually manage versions or changelogs.
How It Works
-
You commit using conventional commit format (see above)
-
release-please creates/updates a release PR automatically when changes are pushed to
main- Updates version in
package.json - Updates
CHANGELOG.md - Generates release notes
- Updates version in
-
Maintainer merges the release PR when ready to release
- Creates a GitHub release and git tag
- Automatically publishes to npm with provenance
Version Bumps
Versions follow Semantic Versioning:
- Major (1.0.0 → 2.0.0): Breaking changes (
feat!:,fix!:, orBREAKING CHANGE:) - Minor (1.0.0 → 1.1.0): New features (
feat:) - Patch (1.0.0 → 1.0.1): Bug fixes (
fix:)
Commits with types like docs:, test:, chore: don't trigger releases on their own.
For Maintainers Only
Publishing is fully automated via GitHub Actions:
- Merge the release-please PR when ready
- GitHub Actions will automatically publish to npm with provenance
- No manual
npm publishneeded
Questions?
- Open an issue for bugs or feature requests
- Check existing issues and PRs before creating new ones
- Tag your issues appropriately (
bug,enhancement,documentation, etc.)
License
By contributing to @supabase/server, you agree that your contributions will be licensed under the MIT License.