Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
245 lines (173 loc) · 4.26 KB

CONTRIBUTING.md

File metadata and controls

245 lines (173 loc) · 4.26 KB
Raw

Contributing to Scent

This document outlines the development workflow and rules to keep the codebase consistent and maintainable.

Navigation

  1. Project Setup
  2. Development Flow
  3. Branch Naming
  4. Branch Strategy
  5. Commit Convention
  6. Pull Requests
  7. What Should Not Be Committed
  8. Code Style
  9. Definition of Done
  10. Notes

Project Setup

Clone the repository

git clone https://github.com/Abviol/scent.git

Copy variables from .env.example to .env

cp .env.example .env

Install dependencies

pnpm install

Start development server

pnpm dev

Build project

pnpm build

Lint code

pnpm lint

Development Flow

  1. Create branch from dev
  2. Implement changes
  3. Run pnpm lint + pnpm build
  4. Open PR targeting dev
  5. Merge after review/checks

Branch Naming

Use the following convention:

type/short-description

Branch types:

  • feat: new feature
  • fix: bug fix
  • refactor: code change without behavior change
  • docs: documentation only
  • style: formatting (no logic changes)
  • test: adding/updating tests
  • chore: maintenance (build tools, deps, etc.)

Examples:

  • feat/cart-drawer
  • fix/hydration-issue
  • refactor/navbar-state
  • docs/readme-update

Branch Strategy

  • main → production
  • dev → active development

PRs target dev; dev is merged into main only for releases.

Commit Convention

We use Conventional Commits:

type(scope): subject

Body: explanation of what changed and why (optional)

Footer: links / breaking changes (optional)

1. Type (required)

  • feat: new feature
  • fix: bug fix
  • refactor: code change without behavior change
  • docs: documentation only
  • style: formatting (no logic changes)
  • test: adding/updating tests
  • chore: maintenance (build tools, deps, etc.)

2. Scope (optional)

What part of the app is affected.

Examples:

  • cart
  • navbar
  • auth
  • checkout
  • api

3. Subject (required)

Short description of the change

Rules:

  • imperative mood (“add”, not “added”)
  • lowercase
  • no period at the end
  • ideally ≤ 50–72 characters

Example:

feat(cart): add drawer animation

4. Body (optional)

Why and what in detail.

Implemented smooth slide-in animation using Framer Motion.
Improves UX consistency with design system.

5. Footer (optional)

Used for metadata like:

  • breaking changes
  • issue references
fix(auth): prevent login crash on empty input

Closes #42

or

feat(api): change response format

BREAKING CHANGE: response now returns `userData` instead of `user`

Full commit example

feat(cart): add drawer animation

Implemented slide-in cart drawer with focus trap and escape handling.
Improves accessibility and aligns with design specs.

Closes #18

Pull Requests

Before opening a PR:

  • Ensure the branch is up to date with dev
  • Run pnpm build
  • Run pnpm lint
  • Test changes locally

PR Naming Convention

PR titles use the same format as commit messages:

type(scope): short description

PR requirements:

  • Clear description
  • Screenshots (if UI changes)
  • All (applicable) checklist items completed

See /.github/pull_request_template.md

What should NOT be committed

  • console.log left in code
  • commented-out code
  • unused imports
  • debug flags

Code Style

See Code Conventions for the full coding standards applied across the codebase.

Definition of Done

A task is considered complete when:

  • Feature works as expected
  • No ESLint errors
  • No console errors
  • Fully responsive (obligatory after the Phase 5 is reached, see README.md)
  • Accessible (keyboard + ARIA where needed)
  • Types are correct
  • UI matches design
  • Code is reviewed and clean

Notes

This project is designed as a portfolio-level production simulation.
Quality, consistency, and clarity matter more than speed.