Skip to main content
Thank you for considering contributing to Resolid Framework! Before you submit your contribution, please take a moment to read the following guidelines.

​
How to Contribute

Follow these steps to contribute to Resolid Framework:
1

Fork the repository

Create your own copy of the project to work on.
2

Clone your fork locally

git clone https://github.com/<your-username>/resolid-framework.git
cd resolid-framework
3

Install dependencies

pnpm install
4

Create a new branch

Use a descriptive branch name related to your change:
git checkout -b feat/awesome-feature
5

Make your changes

  • Follow the Clean Code Rules.
  • Write tests for new features or bug fixes.
6

Run tests

pnpm run test
7

Commit your changes

Use the Conventional Commit format.
8

Push to your branch

git push origin feat/awesome-feature
9

Open a Pull Request (PR)

  • Target the main branch of the original repository.
  • Provide a clear description of your changes, why they are needed, and reference any relevant issues.
10

Address review comments

  • Make changes if requested.
  • Update tests or documentation as needed.

​
Tips

  • Keep PRs small and focused — one logical change per PR.
  • Ensure your code passes linting and type checks before submitting.
  • Use meaningful commit messages to make reviewing easier.

​
Clean Code Rules

The Resolid Framework follows the principles of Clean Code to ensure that code remains simple, readable, and maintainable. Following these guidelines makes your code easier to read, test, and maintain.

Intention-revealing names

Use names that make the purpose obvious

Single responsibility

Each function should do one thing and do it well

Side effects at boundary

Keep I/O, state, and network operations isolated

Guard clauses first

Prefer guard clauses to reduce nesting

Symbolize constants

Avoid hardcoded literals

Input → Process → Output

Structure logic in a clear flow

Clear error messages

Report failures with specific errors

Tests as examples

Let tests act as usage examples, covering both normal and edge cases

​
Commit Convention Rules

Follow the Conventional Commits specification via @commitlint/config-conventional. The commit message should be structured as follows: 
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

​
Rules

  • Allowed types: build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test
  • Type must be lowercase and non-empty
  • Subject must:
    • not be empty
    • not end with period (.)
    • Avoid sentence case, start case, PascalCase, or UPPER_CASE
  • Header max length: 100 characters
  • Body and footer:
    • Must start with a blank line after the header
    • Maximum line length: 100 characters
  • Breaking changes:
    • Indicate using BREAKING CHANGE: in the footer
    • Precede it with a blank line

​
Commit Examples

feat(di): add LazyResolve support for async factory
fix(core): handle null input gracefully
perf(di): optimize dependency resolution
chore: update dependencies

Build docs developers (and LLMs) love

Get started for freeTalk to us