Index your code with Devin
DeepWiki

doocs/leetcode

Menu

Development Workflow

Relevant source files

This document describes the development workflow for contributing to the LeetCode solutions repository, including local quality gates, automated CI/CD pipelines, and the pull request lifecycle. Contributors use this workflow to add new solutions, update existing code, and maintain documentation quality across 10+ programming languages.

For information about the repository structure and problem organization, see Problem Organization. For details about multi-language code formatting standards, see Code Formatting System.

Local Development Quality Gates

The repository enforces code quality through pre-commit hooks that run automatically before commits are created. These local checks catch formatting and style issues before code reaches CI/CD pipelines.

Pre-commit Hook System (Husky)

The repository uses Husky to manage Git hooks. When developers run npm install, Husky automatically installs pre-commit hooks configured in package.json2-4

The prepare script executes during npm install, setting up Git hooks that intercept commit operations.

Lint-Staged Configuration

The lint-staged tool runs formatters only on files that are staged for commit, optimizing performance by avoiding full repository scans. Configuration is defined in package.json15-19:

File PatternFormatterPurpose
*.{js,ts,php,sql,md}prettier --writeFormat JavaScript, TypeScript, PHP, SQL, Markdown
*.pyblack -SFormat Python (skip string normalization)
*.rsrustfmtFormat Rust

The -S flag for Black prevents string quote normalization, preserving the repository's existing string style conventions.

Commitlint Validation

Commit messages must follow Conventional Commits specification, enforced by @commitlint/config-conventional package.json6-7 Valid commit types include:

  • feat: - New problem solutions
  • fix: - Bug fixes in existing solutions
  • docs: - Documentation updates
  • style: - Code formatting (no logic changes)
  • refactor: - Code restructuring
  • test: - Test additions or modifications
  • chore: - Maintenance tasks

Example valid commit:

feat: add solution for problem 125 in Go

Added two-pointer solution with O(n) time complexity

Prettier Configuration

Code style is unified through Prettier with specific settings in .prettierrc1-22:

SettingValueImpact
tabWidth4Consistent indentation across languages
singleQuotetrueUse single quotes in JavaScript/TypeScript
printWidth100Maximum line length
phpVersion"8.1"PHP syntax targeting
sqlKeywordCase"upper"SQL keywords in uppercase

Special plugins handle domain-specific formatting:

  • prettier-plugin-sql-cst for SQL files
  • @prettier/plugin-php for PHP files

Sources: package.json1-20 .prettierrc1-22

Automated CI/CD Workflows

GitHub Actions orchestrates all automation, from code formatting to deployment. Workflows are triggered by pushes, pull requests, schedules, or manual dispatches.

Workflow Trigger Architecture

Concurrency Control: All workflows use group: ${{github.workflow}} - ${{github.ref}} with cancel-in-progress: true to prevent redundant runs when new commits are pushed.

Sources: .github/workflows/deploy.yml17-19 .github/workflows/prettier.yml7-9 .github/workflows/black-lint.yml23-25

Deploy Workflow (deploy.yml)

The main deployment workflow builds bilingual documentation sites and publishes to GitHub Pages. It runs on pushes to main that modify solution directories.

Key Implementation Details:

  1. Dual Branch Strategy: Content from main branch is merged with configuration from docs branch using rsync .github/workflows/deploy.yml37-40
  2. Caching: Pip dependencies and MkDocs Material assets are cached to speed up builds .github/workflows/deploy.yml54-68
  3. Preprocessing: Python script main.py runs before MkDocs to generate dynamic content .github/workflows/deploy.yml82
  4. Committer Cache: Git committer information is cached and committed back to docs branch for author attribution .github/workflows/deploy.yml89-112
  5. Compression: Built site is compressed to site.tar.gz for artifact upload, reducing transfer time .github/workflows/deploy.yml114-124

Environment Variables:

Sources: .github/workflows/deploy.yml1-154

Code Formatting Workflows

Three separate workflows handle formatting for different language ecosystems:

Prettier Workflow (prettier.yml)

Runs on pull_request_target to format files from external contributors. Uses pull_request_target instead of pull_request to access repository secrets safely .github/workflows/prettier.yml4-5

Process:

  1. Checkout from PR head repository .github/workflows/prettier.yml20-22
  2. Install Node.js and dependencies .github/workflows/prettier.yml23-28
  3. Detect changed files: git diff --name-only filtered by \.js$|\.ts$|\.php$|\.sql$|\.md$ .github/workflows/prettier.yml32
  4. Run npx prettier --write on changed files only .github/workflows/prettier.yml35
  5. Auto-commit with message "style: format code and docs with prettier" .github/workflows/prettier.yml39-44

Identity: Commits are made by idoocs bot (doocs-bot@outlook.com) .github/workflows/prettier.yml43-44

Black Linter Workflow (black-lint.yml)

Validates Python code formatting on pushes and PRs. Does not auto-fix; contributors must run Black locally .github/workflows/black-lint.yml1-36

Trigger Paths:

  • solution/**
  • lcs/**, lcp/**, lcof2/**, lcof/**, lcci/**
  • basic/**

Configuration: Uses jpetrucciani/black-check@24.2.0 action with -S flag to skip string normalization .github/workflows/black-lint.yml33-35

Clang Format Linter Workflow (clang-format-lint.yml)

Similar to Black workflow but for C, C++, and Java files. Validates formatting without auto-fixing .github/workflows/clang-format-lint.yml1-36

Sources: .github/workflows/prettier.yml1-45 .github/workflows/black-lint.yml1-36 .github/workflows/clang-format-lint.yml1-36

Asset Generation Workflows

Starcharts Workflow (starcharts.yml)

Updates the star growth chart every 12 hours using cron schedule "0 0/12 * * *" .github/workflows/starcharts.yml5

Process:

  1. Uses MaoLongLong/actions-starcharts@main action .github/workflows/starcharts.yml14
  2. Generates SVG chart at images/starcharts.svg .github/workflows/starcharts.yml17
  3. Commits with message "chore: auto update starcharts" .github/workflows/starcharts.yml18
  4. Uses secret STARS_CHANGE to track star count deltas .github/workflows/starcharts.yml19

Output: The SVG is embedded in README via <img src="./images/starcharts.svg"> README.md201

Image Compression Workflow (compress.yml)

Optimizes images on push, PR, weekly schedule, and manual dispatch. Uses Calibre's image-actions tool .github/workflows/compress.yml28-55

Behavior:

Tool: calibreapp/image-actions@main optimizes JPEG, PNG, WebP formats .github/workflows/compress.yml40

Sources: .github/workflows/starcharts.yml1-20 .github/workflows/compress.yml1-55

Pull Request Workflow

The PR lifecycle includes automated checks, team member detection, and maintainer review before merge.

Fork and Branch Strategy

Contributors follow the standard GitHub fork workflow described in README.md182-191:

Branch Naming Convention: While not enforced, descriptive names like feat/problem-125-go or docs/update-contributing help identify PR purpose.

Sources: README.md182-191

Automated Checks on Pull Requests

When a PR is opened, GitHub Actions run multiple validation workflows:

Prettier Auto-fix Behavior: Unlike Black/Clang-format workflows that only validate, Prettier workflow automatically commits formatting fixes using stefanzweifel/git-auto-commit-action@v5 .github/workflows/prettier.yml39-44

Team Member Detection: The pr-add-label.yml workflow checks if PR author belongs to doocs/leetcode-algorithm team and adds appropriate labels .github/workflows/pr-add-label.yml19-25:

Team members' PRs are marked for priority review.

Sources: .github/workflows/prettier.yml1-45 .github/workflows/black-lint.yml1-36 .github/workflows/pr-add-label.yml1-26

Review and Merge Process

After automated checks pass:

  1. Maintainer Review: Project maintainers review code quality, solution correctness, and documentation completeness
  2. Feedback Incorporation: Contributors address review comments by pushing new commits to the same branch
  3. Merge: Maintainers merge PR to main branch
  4. Automatic Deployment: Deploy workflow triggers, building and publishing updated documentation to leetcode.doocs.org .github/workflows/deploy.yml6-15

Deployment Trigger: Only pushes to main affecting solution paths trigger deployment:

Sources: .github/workflows/deploy.yml6-15 README.md182-191

Contribution Guidelines

Step-by-Step Contribution Process

The repository welcomes contributions of new solutions, improvements to existing solutions, and documentation updates. The process is documented in README.md182-195:

  1. Fork Repository: Navigate to https://github.com/doocs/leetcode and click "Fork"
  2. Clone Fork: git clone https://github.com/YOUR_USERNAME/leetcode
  3. Create Branch: git checkout -b feat/add-solution-125 (use descriptive name)
  4. Make Changes: Add solution files following directory structure conventions
  5. Test Locally:
    • Ensure solution code runs correctly
    • Verify README renders properly
    • Run formatters: npm install && git add . && git commit -m "test" (triggers pre-commit hooks)
  6. Push Changes: git push origin feat/add-solution-125
  7. Create PR: Open pull request from your fork to doocs/leetcode:main
  8. Address Feedback: Respond to review comments and push additional commits

Directory Structure Conventions

Solutions are organized by problem series and number ranges. For standard LeetCode problems:

Path Pattern: solution/[RANGE]/[PROBLEM_ID].[Problem Title]/

Example: Problem 125 "Valid Palindrome"

solution/0100-0199/0125.Valid Palindrome/
├── README.md          # Chinese description and solutions
├── README_EN.md       # English description and solutions  
├── Solution.py        # Python implementation
├── Solution.java      # Java implementation
├── Solution.cpp       # C++ implementation
├── Solution.go        # Go implementation
├── Solution.ts        # TypeScript implementation
├── Solution.rs        # Rust implementation
└── ...                # Other languages

Range Directories:

  • 0000-0099/ - Problems 0-99
  • 0100-0199/ - Problems 100-199
  • ...
  • 3700-3799/ - Problems 3700-3799

Other Series:

  • lcof/ - 剑指 Offer (2nd Edition)
  • lcof2/ - 剑指 Offer (Special Edition)
  • lcci/ - Cracking the Coding Interview (6th Edition)
  • lcp/ - LeetCode Cup contest problems
  • lcs/ - LeetCode Season contest problems
  • basic/ - Basic algorithms (sorting, searching)

Sources: README.md26-30 solution/0100-0199/0125.Valid Palindrome/README.md1-10

Solution File Template Structure

Each solution file should follow language-specific patterns:

Python Solution Template

Java Solution Template

Formatting Requirements:

  • Python: Follow Black style (4-space indent, no string normalization)
  • Java/C++: Follow clang-format style
  • JavaScript/TypeScript: Follow Prettier style (4-space indent, single quotes)
  • All: Maximum line length 100 characters

README Documentation Structure

Each problem directory must contain bilingual README files following this template:

README.md (Chinese):

Example: See solution/0100-0199/0125.Valid Palindrome/README.md1-80 for complete template

Required Elements:

  1. YAML frontmatter with comments, difficulty, edit_url, tags
  2. Problem title with LeetCode link
  3. Link to English version
  4. Problem description (题目描述)
  5. Solution explanation (解法) with complexity analysis
  6. Code tabs for each language implementation

Sources: solution/0100-0199/0125.Valid Palindrome/README.md1-224 solution/0100-0199/0125.Valid Palindrome/README_EN.md1-224

Basic Algorithm Contributions

The basic/ directory contains tutorial-style explanations of fundamental algorithms. Structure:

basic/
├── README.md              # Index (Chinese)
├── README_EN.md           # Index (English)
├── sorting/
│   ├── BubbleSort/
│   │   └── README.md      # Tutorial with code examples
│   ├── QuickSort/
│   │   └── README.md
│   └── ...
└── searching/
    └── BinarySearch/
        └── README.md

Tutorial Format: Each algorithm tutorial should include:

  1. Conceptual explanation
  2. Algorithm template/pseudocode
  3. Complexity analysis
  4. Code implementations in multiple languages
  5. Example usage

Example: basic/sorting/BubbleSort/README.md1-220 demonstrates the standard tutorial format with Python, Java, C++, Go, Rust, JavaScript, and C# implementations.

Sources: basic/README.md1-32 basic/sorting/BubbleSort/README.md1-220 basic/searching/BinarySearch/README.md1-60

Commit Message Guidelines

All commits must follow Conventional Commits specification enforced by commitlint. Valid format:

<type>(<scope>): <subject>

<body>

<footer>

Common Types:

TypeUsageExample
featNew solutionfeat: add solution for problem 125 in Python
fixBug fixfix: correct time complexity in problem 200
docsDocumentationdocs: update README for binary search tutorial
styleFormattingstyle: format code with black
refactorCode restructurerefactor: optimize space complexity in problem 1
testTeststest: add test cases for problem 125
choreMaintenancechore: update dependencies

Scope (Optional): Can specify problem number, directory, or component

  • feat(0125): add Go solution
  • docs(basic): add merge sort tutorial

Auto-generated Commits: Workflow bots use specific formats:

  • "style: format code and docs with prettier" - Prettier workflow
  • "chore: auto update starcharts" - Starcharts workflow
  • "chore: auto compress images" - Image compression workflow

Sources: package.json6-7 .github/workflows/prettier.yml42 .github/workflows/starcharts.yml18

Language-Specific Guidelines

Python

  • Use Black formatter with -S flag (skip string normalization)
  • Type hints encouraged: def method(self, nums: List[int]) -> int:
  • Class-based solutions: class Solution:
  • Dependencies: Listed in requirements.txt1-2 (black, requests)

Java

  • Use clang-format style
  • Package declaration optional in solution files
  • Standard class name: class Solution {}

C++

  • Use clang-format style
  • Include guards not required for solution files
  • Prefer STL containers: vector<int>, unordered_map<int, int>

Go

  • Use gofmt formatting (standard)
  • Package name: package main or omit for solution snippets
  • Function signature: func methodName(param Type) ReturnType {}

TypeScript/JavaScript

  • Use Prettier with .prettierrc1-22 settings
  • 4-space indentation, single quotes
  • Export solution: function methodName(param: Type): ReturnType {}

Rust

  • Use rustfmt (standard)
  • Implementation in impl Solution {} block
  • Prefer &str over String for string parameters when possible

Sources: package.json15-19 requirements.txt1-2 .prettierrc1-22

Common Issues and Troubleshooting

Pre-commit Hook Failures

Issue: Commit rejected with formatting errors

Solution:

  1. Install dependencies: npm install
  2. Stage files: git add .
  3. Commit again: git commit -m "your message"
  4. Hooks auto-format on second attempt

Manual Formatting:

Black Lint CI Failure

Issue: black-lint.yml workflow fails on PR

Cause: Python code not formatted with Black

Solution:

Prettier Workflow Not Fixing Code

Issue: Prettier workflow runs but doesn't commit fixes

Cause: Workflow only runs on pull_request_target for external contributors

Solution: For maintainers and team members, format locally before pushing:

Image Optimization Not Triggering

Issue: Added images but compress workflow didn't run

Cause: Workflow only triggers on specific paths:

Solution: Ensure image files use supported extensions. Manually trigger via Actions tab if needed.

Sources: .github/workflows/compress.yml6-17

Additional Resources

Community Support:

Sources: README.md220-227