Skip to main content

Contributing to Opal Editor

Thank you for your interest in contributing to Opal Editor! This guide will help you get started with the development process and ensure your contributions align with project standards.

Getting Started

Prerequisites

  • Node.js: Version 22.19.0 or higher (see ~/workspace/source/package.json:196-198)
  • npm: Comes with Node.js
  • Git: For version control

Development Setup

  1. Clone the repository
git clone https://github.com/rbbydotdev/opal.git
cd opal
  1. Install dependencies
npm install
This will install all required dependencies and apply necessary patches via patch-package.
  1. Start the development server
npm run dev
The application will be available at http://localhost:3000.

Development Scripts

Opal Editor provides several npm scripts for development:
ScriptPurpose
npm run devStart Vite development server
npm run dev:allRun app and build workers in parallel
npm run buildBuild production bundle
npm run build:workersBuild web workers
npm run typecheckRun TypeScript type checking
npm run lintRun ESLint checks
npm testRun Playwright tests
See ~/workspace/source/package.json:6-28 for the complete list.

Code Style and Conventions

TypeScript Configuration

Opal Editor uses strict TypeScript settings (see ~/workspace/source/tsconfig.json:1-48):
  • Strict mode enabled: All strict type-checking options are on
  • No unchecked indexed access: Always check for undefined when accessing array/object properties
  • No implicit any: All types must be explicitly defined
  • Path aliases: Use @/* to import from src/*

ESLint Rules

The project enforces code quality through ESLint (see ~/workspace/source/eslint.config.mjs:1-52): Key rules:
  • No floating promises: All promises must be properly awaited or handled
  • React Hooks exhaustive deps: Dependency arrays must be complete
  • Custom hooks: useAsyncEffect, useRemoteResource, useRunner, and useResource are checked for dependencies
  • Unused variables: Variables starting with _ are ignored
Run linting:
npm run lint

Code Formatting

The project uses Prettier for code formatting:
  • Use 2 spaces for indentation
  • Use double quotes for strings
  • Add trailing commas where valid
  • Format on save is recommended

Naming Conventions

  • Components: PascalCase (e.g., WorkspaceList.tsx)
  • Files: camelCase for utilities, PascalCase for components
  • Variables: camelCase
  • Constants: UPPER_SNAKE_CASE for true constants
  • Types/Interfaces: PascalCase

Development Workflow

1. Find an Issue or Feature

  • Check the GitHub Issues for open tasks
  • Look for issues labeled good first issue or help wanted
  • Join the Discord server to discuss ideas
  • Comment on an issue to indicate you’re working on it

2. Create a Branch

Create a descriptive branch name:
git checkout -b feature/workspace-templates
git checkout -b fix/editor-cursor-jump
git checkout -b docs/update-api-reference
Use prefixes:
  • feature/ - New features
  • fix/ - Bug fixes
  • docs/ - Documentation updates
  • refactor/ - Code refactoring
  • test/ - Test additions or updates

3. Make Your Changes

  • Write clean, well-documented code
  • Follow the existing code style and patterns
  • Add comments for complex logic
  • Update documentation as needed
  • Ensure TypeScript types are correct

4. Test Your Changes

Run type checking:
npm run typecheck
Run linting:
npm run lint
Run tests:
npm test
See the Testing Guide for detailed testing information.

5. Commit Your Changes

Write clear, descriptive commit messages:
git add .
git commit -m "feat: add workspace template selection"
git commit -m "fix: resolve cursor jump in markdown editor"
git commit -m "docs: update API reference for build service"
Commit message format:
  • feat: - New features
  • fix: - Bug fixes
  • docs: - Documentation changes
  • style: - Code style changes (formatting, etc.)
  • refactor: - Code refactoring
  • test: - Test updates
  • chore: - Build process or tooling changes

Pull Request Process

1. Push Your Branch

git push origin feature/your-feature-name

2. Create a Pull Request

  1. Go to github.com/rbbydotdev/opal
  2. Click “Pull requests” > “New pull request”
  3. Select your branch
  4. Fill out the PR template with:
    • Description: What does this PR do?
    • Motivation: Why is this change needed?
    • Changes: What files/components were modified?
    • Testing: How was this tested?
    • Screenshots: For UI changes (if applicable)

3. PR Requirements

Before your PR can be merged:
  • ✅ All tests must pass
  • ✅ Code must pass TypeScript checks (npm run typecheck)
  • ✅ Code must pass ESLint checks (npm run lint)
  • ✅ No merge conflicts
  • ✅ Description clearly explains the changes
  • ✅ At least one maintainer approval

4. Address Review Feedback

  • Respond to review comments
  • Make requested changes
  • Push updates to your branch (PR will update automatically)
  • Re-request review after making changes

5. Merge

Once approved, a maintainer will merge your PR. Thank you for your contribution!

Project Structure

Key directories to know:
src/
├── components/       # React components
├── data/            # Data layer (Dexie, DAO)
├── services/        # Business logic services
├── lib/             # Utility functions
├── hooks/           # Custom React hooks
└── routes/          # Application routes (Tanstack Router)

playwright-tests/    # E2E tests
public/              # Static assets

Architecture Notes

  • Local-first: Uses IndexedDB (Dexie) and OPFS for storage
  • Git integration: Built on isomorphic-git
  • State management: Valtio for reactive state
  • Routing: Tanstack Router
  • UI: Radix UI + Tailwind CSS
  • Editor: MDX Editor (WYSIWYG) + CodeMirror (raw markdown)

Getting Help

Code of Conduct

  • Be respectful and inclusive
  • Provide constructive feedback
  • Focus on what is best for the community
  • Show empathy towards other community members

License

By contributing to Opal Editor, you agree that your contributions will be licensed under the same license as the project. Thank you for contributing to Opal Editor! Your efforts help make this tool better for everyone.

Build docs developers (and LLMs) love