Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
146 lines (98 loc) · 9.23 KB

CONTRIBUTING.md

File metadata and controls

146 lines (98 loc) · 9.23 KB

Welcome to Fusion Framework contributing guide

Thank you for investing your time in contributing to our project!

Read our Code of Conduct to keep our community approachable and respectable.

In this guide you will get an overview of the contribution workflow from opening an issue, creating a PR, reviewing, and merging the PR.

New contributor guide

To get an overview of the project, read the README. Here are some resources to help you get started with open source contributions:

Getting started

Issues

Create a new issue

If you spot a problem with the docs, search if an issue already exists. If a related issue doesn't exist, you can open a new issue using a relevant issue form.

Solve an issue

Scan through our existing issues to find one that interests you. You can narrow down the search using labels as filters. If you find an issue to work on, you are welcome to open a PR with a fix.

Make Changes

Make changes locally

  1. Fork the repository.

  1. Install or update to Node.js, at the version specified in .node-version. For more information, see the development guide.

  2. Create a working branch and start with your changes!

Non-negotiable code standards

The primary goal of our standards is to capture intent, not just syntax.

  • All declared functions, named arrow functions, components, hooks, and classes must have TSDoc that explains intent
  • TSDoc must include @param, @returns, @template for generics, and @example for user-facing APIs
  • Iterator blocks, decision gates, RxJS operator chains, and complex decisions must explain why they exist with inline comments or extracted named helpers
  • In React code, resolve data transforms and decision logic before markup so JSX stays focused on composition
  • User-facing changes must update package README.md, and advanced or noisy material must be moved into packages/*/docs/

See contributing/code-standards.md, contributing/documentation.md, and contributing/self-review.md for the full standards.

Commit your update

Your commits should adhere to our guidelines and follow a linear history.

Caution

☠️ do not include files in your commit which are outside the scope of the commit!

Important

Don't forget to self-review to speed up the review process⚡️.

Tip

Rebase your commits 😍

The important part is to provide a good history. Git should not be used as a 'backup'. Commit frequency should not be determined by a time etc.

Be smart and think how you would have wanted to visit the history at a later time.

Pull Request

Important

The PR description is a critical part of our maintainer documentation. A well-written description allows anyone — now or years later — to quickly understand why a change was made, what the impact is, and how to verify it, without needing to read every line of code in the diff.

Tip

The PR template (.github/PULL_REQUEST_TEMPLATE.md) contains inline guidance and examples. Always use the template without adding a free-form summary at the top — either keep the headers and fill them in, or replace the template with a clear narrative that still covers all required aspects.

Before opening a new PR:

  • All affected packages have matching changesets
  • Make sure the code builds: pnpm build
  • Make sure the code lints: pnpm lint
  • Make sure tests pass: pnpm test run
  • Make sure the change captures intent in TSDoc, inline comments, and README/docs where required

When you're finished with the changes, create a pull request.

Warning

All PRs should be created as draft initially.

  • Select the matching pull request template.
  • Fill out every section of the template completely (remove HTML comments, answer all questions):
    • Especially the Why section (motivation, current behavior, new behavior, breaking changes, context, related issues)
    • Explicitly describe the intended behavior, invariants, and non-obvious decisions
    • Include clear guidance on How to review/test (files to focus on, commands to run, scenarios to try)
    • Describe the Impact (who benefits, performance/security implications, migration needs, scope/risks)
  • Don't forget to link the PR to the issue if you are solving one.
  • Enable the checkbox to allow maintainer edits so the branch can be updated for merge.

When all checks are green and the description is complete, mark the PR as "Ready for review"

Pull requests that trigger ready_for_review will post to our Teams channel.

Once you submit your PR, a Fusion Core team member will review your proposal. We may ask questions or request additional information.

Caution

Missing intent documentation is review-blocking.

Expect changes requested if a PR omits required TSDoc, leaves non-trivial control flow unexplained, keeps business logic in React markup, or fails to update README/docs for user-facing changes.

  • We may ask for changes to be made before a PR can be merged, either using suggested changes or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
  • As you update your PR and apply changes, mark each conversation as resolved.
  • If you run into any merge issues, check out this git tutorial to help you resolve merge conflicts and other issues.

Warning

When a pull request review requests changes, the pull request is moved back to draft.

When a pull request is moved back to draft, it is the creator's responsibility to request a re-review once updates are made.

Caution

When a pull request review is approved, the creator is normally responsible for merging the code.

Tip

Enable "auto-merge" on approved PRs to speed things up.

Your PR is merged!

Congratulations 🎉 The Fusion team thanks you 😘

Windows

This code base can be developed on Windows, however a few potential gotchas need to be kept in mind:

  1. Regular Expressions: Windows uses \r\n for line endings, while Unix-based systems use \n. Therefore, when working on Regular Expressions, use \r?\n instead of \n in order to support both environments. The Node.js os.EOL property can be used to get an OS-specific end-of-line marker.
  2. Paths: Windows systems use \ for the path separator, which would be returned by path.join and others. You could use path.posix, path.posix.join etc and the slash module, if you need forward slashes - like for constructing URLs - or ensure your code works with either.
  3. Bash: Not every Windows developer has a terminal that fully supports Bash, so it's generally preferred to write scripts in JavaScript instead of Bash.
  4. Filename too long error: There is a 260 character limit for a filename when Git is compiled with msys. While the suggestions below are not guaranteed to work and could cause other issues, a few workarounds include:
    • Update Git configuration: git config --system core.longpaths true
    • Consider using a different Git client on Windows