# Welcome to Fusion Framework contributing guide <!-- omit in toc -->

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

Read our [Code of Conduct](./CODE_OF_CONDUCT.md) 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](README.md). 
Here are some resources to help you get started with open source contributions:

- [Finding ways to contribute to open source on GitHub](https://docs.github.com/en/get-started/exploring-projects-on-github/finding-ways-to-contribute-to-open-source-on-github)
- [Set up Git](https://docs.github.com/en/get-started/quickstart/set-up-git)
- [GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow)
- [Collaborating with pull requests](https://docs.github.com/en/github/collaborating-with-pull-requests)

## Getting started

### Issues

#### Create a new issue

If you spot a problem with the docs, [search if an issue already exists](https://docs.github.com/en/github/searching-for-information-on-github/searching-on-github/searching-issues-and-pull-requests#search-by-the-title-body-or-comments). If a related issue doesn't exist, you can open a new issue using a relevant [issue form](https://github.com/equinor/fusion-framework/issues/new/choose).

#### Solve an issue

Scan through our [existing issues](https://github.com/equinor/fusion-framework/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.
- Using GitHub Desktop:
  - [Getting started with GitHub Desktop](https://docs.github.com/en/desktop/installing-and-configuring-github-desktop/getting-started-with-github-desktop) will guide you through setting up Desktop.
  - Once Desktop is set up, you can use it to [fork the repo](https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/cloning-and-forking-repositories-from-github-desktop)!

- Using the command line:
  - [Fork the repo](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo#fork-an-example-repository) so that you can make your changes without affecting the original project until you're ready to merge them.

2. Install or update to **Node.js**, at the version specified in `.node-version`. For more information, see [the development guide](contributing/development.md).

3. 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/code-standards.md), [contributing/documentation.md](contributing/documentation.md), and [contributing/self-review.md](contributing/self-review.md) for the full standards.

### Commit your update

Your commits should adhere to [our guidelines](contributing/conventional-commits.md) 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](contributing/self-review.md) 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](./contributing/changeset.md)
- 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](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) if you are solving one.
- Enable the checkbox to [allow maintainer edits](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork) 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](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request) 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](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request#resolving-conversations).
- If you run into any merge issues, check out this [git tutorial](https://github.com/skills/resolve-merge-conflicts) 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`](https://nodejs.org/api/os.html#os_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](https://ghub.io/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](/script) 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