Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
87 lines (59 loc) · 2.58 KB

CONTRIBUTING.md

File metadata and controls

87 lines (59 loc) · 2.58 KB

Contributing to Lightning Talks

Thank you for your interest in contributing.

Reporting Bugs

Open a GitHub issue using the Bug Report template. Include:

  • Package version
  • Steps to reproduce
  • Expected vs actual behaviour
  • Relevant CloudFormation error output or stack traces

Proposing Features

Open a GitHub issue using the Feature Request template before writing code. This avoids wasted effort if the feature doesn't fit the project direction.

Development Setup

git clone https://github.com/yourorg/lightning-talks.git
cd lightning-talks

# Install root dependencies (CDK, TypeScript, test tooling)
npm install

# Install frontend dependencies
cd frontend && npm install && cd ..

# Install lambda dependencies
cd lambdas && npm install && cd ..

Copy the example config and fill in your own values:

cp config/example.ts config/dev.ts
# Edit config/dev.ts with your AWS account, domain, and Route 53 zone

Running Tests

# CDK infrastructure tests
npm test

# Lambda handler tests (unit tests, no AWS required)
cd lambdas && npm test

# Frontend tests
cd frontend && npm test

CDK Synth

Validate your changes produce valid CloudFormation without deploying:

cdk synth --context env=dev

Code Conventions

  • TypeScript strict mode is enforced — no any, no implicit returns
  • All public construct props and exported types must have JSDoc comments
  • No hardcoded organisation-specific values (domains, IDs, emails) — use config fields
  • Keep constructs single-responsibility; avoid adding unrelated resources to an existing construct

CDK-Specific Rules

Changing a construct's logical ID or resource structure causes CloudFormation to replace the resource. This is a breaking change even if the TypeScript API hasn't changed. Examples of accidental breaking changes:

  • Renaming a construct in new MyConstruct(this, "OldName") → "NewName"
  • Adding a new parent construct that changes the path
  • Changing a resource property that forces replacement (e.g. DynamoDB table name)

If a breaking infrastructure change is unavoidable, it must be called out explicitly in the PR and in CHANGELOG.md.

Pull Request Process

  1. Branch naming: feat/short-description, fix/short-description, chore/short-description
  2. Link to the relevant GitHub issue
  3. Describe what was changed and how it was tested
  4. Update CHANGELOG.md under [Unreleased] for any user-visible change
  5. Ensure all CI checks pass before requesting review

Commit Style

Use conventional commits: feat:, fix:, chore:, docs:, test:, refactor:.