Skip to content

Latest commit

 

History

History
152 lines (100 loc) · 4.39 KB

CONTRIBUTING.md

File metadata and controls

152 lines (100 loc) · 4.39 KB

Contributing

These instructions will help you begin making changes on your local machine, as well follow our coding guidelines.

Overview

Getting Started
Coding Standards
Making Changes
Testing
Documentation
Branch Naming Conventions
Creating a Pull Request

Getting Started

This project is structured as a monorepo and uses Lerna with Yarn workspaces.

Git Configuration

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.

Development Environment

Copy the snippet below to get your development environment setup:

git clone https://github.com/flex-development/mdjsx.git; cd mdjsx
yarn # or npm install
  • yarn dev:api: Start API dev server on port 8080

Coding Standards

Husky is used to enforce coding and commit message standards.

Commit Messages

This project adheres to Conventional Commits standards.

Commit messages should be one of the following types:

  • build: Changes that affect the build system or external dependencies
  • ci: Changes to our CI configuration files and scripts
  • chore: Changes that don't impact external users
  • docs: Documentation only changes
  • feat: New features
  • fix: Bug fixes
  • perf: Performance improvements
  • refactor: Code improvements
  • revert: Revert past changes
  • style: Changes that do not affect the meaning of the code
  • test: Adding missing tests or correcting existing tests
  • wip: 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:

Formatting & Linting

Formatting

This project uses Prettier to format all code.

To review our formatting guidelines, see our configuration files:

Linting

This project uses ESLint to lint JavaScript and TypeScript files.

To review our linting guidelines, see our configuration files:

Making Changes

For more information on how to make changes within different package scopes, see the Contributing Guide for each package:

Documentation

  • JavaScript & TypeScript: JSDoc

Before making a pull request, be sure your code is well documented, as it will be part of your code review.

Testing

This project uses Jest as its test runner. To run the tests in this project, run yarn test.

Husky is configured to run tests before every push. If a bug report concerning a failed test is needed, you'll be able to push your code even if a test fails.

Branch Naming Conventions

When creating a new branch, the name should match the following format: feature/, hotfix/, release/, or support/ followed by <branch_name>.

For example:

  git feature repo-setup

will create a new branch titled feature/repo-setup and push it to origin.

Creating a Pull Request

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 pr as help wanted.

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.

Submit for Review

  • Use this template
  • Label your pull request appropriately
  • Assign the task to yourself and the appropriate reviewer