These instructions will help you begin making changes on your local machine, as well as follow our coding guidelines.
Getting Started
Coding Standards
Making Changes
Testing
Documentation
Getting Help
Creating a Pull Request
Copy the starter Git global configuration to stay inline with our coding guidelines, as well as begin extending your own workflow.
Note: The examples below will uses aliases from the starter config.
-
Copy the snippet below to clone the project onto your local machine:
git clone https://github.com/flex-development/mango.git; cd mango yarn
Environment variables are documented in package.json
, under
the required-env
field.
Husky is used to enforce coding and commit message standards.
When creating a new branch, the name should match the following format:
feat/
, hotfix/
, release/
, or support/
followed by
<branch_name>
.
For example:
git feat repo-setup
will create a new branch titled feat/repo-setup
and push it to origin
.
This project follows Conventional Commits standards.
Commit messages should be one of the following types:
build
: Changes that affect the build system or external dependenciesci
: Changes to our CI configuration files and scriptschore
: Changes that don't impact external usersdocs
: Documentation only changesfeat
: New featuresfix
: Bug fixesperf
: Performance improvementsrefactor
: Code improvementsrevert
: Revert past changesstyle
: Changes that do not affect the meaning of the codetest
: Adding missing tests or correcting existing testswip
: Working on changes, but you need to go to bed 😉
For example:
git chore "add eslint configuration"
will produce the following commit: chore: add eslint configuration
commitlint is used to enforce commit guidlelines.
To review our commitlint rules, see the configuration file:
This project uses Prettier to format all code.
To review our formatting guidelines, see our configuration files:
- Configuration:
.prettierrc.js
- Ignore Patterns:
.prettierignore
This project uses ESLint to lint JavaScript and TypeScript files.
To review our linting guidelines, see our configuration files:
- Configuration:
.eslintrc.js
- Ignore Patterns:
.eslintignore
All source code can be found in the src
directory.
The purpose of each module is documented using the @file
annotation.
- JavaScript & TypeScript: JSDoc, linted with
eslint-plugin-jsdoc
Before making a pull request, be sure your code is well documented, as it will be part of your code review.
This project uses Jest as its test runner. To run the tests in this
project, run yarn test
from the project root.
Husky is configured to run tests before every push. If a bug report concerning a
failed test is needed, use the command git pnv
to push your code without
running the Husky pre-push
hook.
If you need help, make note of any issues in their respective files. Whenever
possible, create a test to reproduce the error. Make sure to label your issue as
discussion
, help wanted
, and/or question
.
When you're ready to have your changes reviewed, make sure your code is
well documented. The pre-commit
and pre-push
hooks will
test your changes against our coding guidelines, as well run all of the tests in
this project.
- Use this template
- Label your pull request appropriately
- Assign the task to yourself and the appropriate reviewer