Contribute to the Codebase
Follow these guidelines to contribute to the codebase. This is highly recommended if you want to contribute regularly. Ignoring these steps may soil your copy which makes the contributing, maintaining, and reviewing processes difficult.
Contributing to the Codebase
You can now make changes to files and commit your changes to your fork, which you can prepare by reading how to set up freeCodeCamp locally.
Follow these steps:
-
Validate that you are on the
main
branch:You should get an output like this:
If you got a different message, then you aren’t on main or your working directory isn’t clean, resolve any outstanding files/commits and checkout
main
: -
Sync the latest changes from the freeCodeCamp upstream
main
branch to yourmain
fork branch:This step will sync the latest changes from the main repository of freeCodeCamp.
Update your copy of the freeCodeCamp upstream repository:
Hard reset your main branch with the freeCodeCamp main:
Push your main branch to your origin to have a clean history on your fork on GitHub:
You can validate that your current main matches the upstream/main by performing a diff:
The resulting output should be empty. This process is important, because you will be rebasing your branch on top of the latest
upstream/main
as often as possible to avoid conflicts later. -
Create a fresh new branch:
Working on a separate branch for each issue helps you keep your work copy clean. You should never work on the
main
. This will soil your copy of freeCodeCamp and you may have to start over with a fresh clone or fork.Check that you are on
main
as explained previously, and branch off from there:Your branch name should start with a
fix/
,feat/
,docs/
, etc. Avoid using issue numbers in branches. Keep them short, meaningful and unique.Some examples of good branch names are:
-
Edit pages and work on code in your favorite text editor.
-
Once you are happy with the changes you should optionally run freeCodeCamp to preview the changes.
-
Make sure you fix any errors and check the formatting of your changes.
-
Check and confirm the files you are updating:
This should show a list of
unstaged
files that you have edited. -
Stage the changes and make a commit:
In this step, you should only mark files that you have edited or added yourself. You can perform a reset and resolve files that you did not intend to change if needed.
Or you can add all the
unstaged
files to the staging area:Only the files that were moved to the staging area will be added when you make a commit.
Output:
Now, you can commit your changes with a short message like so:
Some examples:
Make a conventional commit message. This is a good practice as a developer, and you will be following standard practices.
Some examples of conventional commit messages are:
Keep these short, not more than 50 characters. You can always add additional information in the description of the commit message.
This does not take any more time than an unconventional message like ‘update file’ or ‘add index.md’
You can learn more about why you should use conventional commits here.
-
If you realize that you need to edit a file or update the commit message after making a commit you can do so after editing the files with:
This will open up a default text editor like
nano
orvi
where you can edit the commit message title and add/edit the description. -
Next, you can push your changes to your fork:
Proposing a Pull Request (PR)
After you’ve committed your changes, check here for how to open a Pull Request.
Quick commands reference
A quick reference to the commands that you will need when working.
command | description |
---|---|
pnpm test | Run all JS tests in the system, including client, server, lint and challenge tests. |
pnpm run test-client | Run the client test suite. |
pnpm run test-client -u | Run the client test suite, updating the Jest snapshots that are out of sync. |
pnpm run test:curriculum | Run the curriculum test suite. |
FCC_BLOCK='Basic HTML and HTML5' pnpm run test:curriculum | Test a specific Block. |
FCC_SUPERBLOCK='responsive-web-design' pnpm run test:curriculum | Test a specific SuperBlock. |
pnpm run test-curriculum-full-output | Run the curriculum test suite, without bailing after the first error |
pnpm run test-server | Run the server test suite. |
pnpm run playwright:run | Run the Playwright end to end tests. |
pnpm run clean | Uninstalls all dependencies and cleans up caches. |
pnpm run storybook | Starts Storybook for component library development. |