title | description | order | toc |
---|---|---|---|
Contributing |
Thank you for contributing to Remix! Here's everything you need to know before you open a pull request. |
6 |
false |
Thanks for contributing, you rock!
When it comes to open source, there are many different kinds of contributions that can be made, all of which are valuable. Here are a few guidelines that should help you as you prepare your contribution.
If you'd like to contribute something—whether it's a bug fix to scratch your own itch or a typo in the docs—we'd be happy to have your contribution. We need you to "sign" a contributor license agreement (CLA) first that assigns us ownership so we are able to include it in this software.
We don't yet have a CLA, but we are working on it and we will be able to accept your contributions as soon as we do. Until then, please keep letting us know about our bugs and typos in Discord and we will do our best to address them.
Before you can contribute to the codebase, you will need to fork the repo. This will look a bit different depending on what type of contribution you are making:
- All new features, bug-fixes, or anything that touches
remix
code should be branched off of and merged into thedev
branch - Changes that only touch documentation can be branched off of and merged into the
main
branch
The following steps will get you setup to contribute changes to this repo:
- Fork the repo (click the Fork button at the top right of this page)
- Clone your fork locally
# in a terminal, cd to parent directory where you want your clone to be, then
git clone https://github.com/<your_github_username>/remix.git
cd remix
# if you are making *any* code changes, make sure to checkout the dev branch
git checkout dev
- Install dependencies and build. Remix uses
yarn
(version 1), so you should too. If you install usingnpm
, unnecessarypackage-lock.json
files will be generated.
Please conform to the issue template and provide a clear path to reproduction with a code example. Best is a pull request with a failing test. Next best is a link to CodeSandbox or repository that illustrates the bug.
Please provide thoughtful comments and some sample code that show what you'd like to do with Remix in your app. It helps the conversation if you can show us how you're limited by the current API first before jumping to a conclusion about what needs to be changed and/or added.
If you need a bug fixed and nobody is fixing it, your best bet is to provide a fix for it and make a pull request. Open source code belongs to all of us, and it's all of our responsibility to push it forward.
Important: When creating the PR in GitHub, make sure that you set the base to the correct branch. If you are submitting a PR that touches any code, this should be the
dev
branch. Pull releases that only change documentation can be merged intomain
.You can set the base in GitHub when authoring the PR with the dropdown below the "Compare changes" heading:
All commits that fix bugs or add features need a test.
<blink>
Do not merge code without tests!</blink>
All commits that change or add to the API must be done in a pull request that also updates all relevant examples and docs.
Remix uses a monorepo to host code for multiple packages. These packages live in the packages
directory.
We use Yarn workspaces to manage installation of dependencies and running various scripts. To get everything installed, make sure you have Yarn (version 1) installed, and then run yarn
or yarn install
from the repo root.
Running yarn build
from the root directory will run the build.
Before running the tests, you need to run a build. After you build, running yarn test
from the root directory will run every package's tests. If you want to run tests for a specific package, use yarn test --projects packages/<package-name>
:
# Test all packages
yarn test
# Test only @remix-run/express
yarn test --projects packages/remix-express
This repo maintains separate branches for different purposes. They will look something like this:
- main > the most recent release and current docs
- dev > code under active development between stable releases
There may be other branches for various features and experimentation, but all of the magic happens from these branches.