Skip to content

Latest commit

 

History

History
200 lines (136 loc) · 5.95 KB

CONTRIBUTING.md

File metadata and controls

200 lines (136 loc) · 5.95 KB
Raw

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
Getting Help
Creating a Pull Request

Getting Started

This project is structured as a monorepo and uses Lerna with Yarn workspaces. All projects are deployed with Vercel.

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

  1. Copy the snippet below to clone the project onto your local machine:

    git clone https://github.com/flex-development/JIME-P001.git; cd JIME-P001
yarn # or npm install

  2. Retrieve the following files from a development admin:

    • kapi.json
    • kustomzdesign.json
    • morenaskustomz.json

    Place them in the root of the project directory.

  3. To finish configuring your Vercel development environment:

    mv kapi.json ~/.vercel/kapi.json;
mkdir packages/system/.vercel;
mv kustomzdesign.json packages/system/.vercel/project.json;
mkdir packages/app/.vercel;
mv morenaskustomz.json packages/app/.vercel/project.json;

  4. Run the project!

    • yarn dev:api: Start API on port 8080
    • yarn dev:store: Start Next.js app on port 3001; API on port 8080
    • yarn dev:store-ui: Start Storybook app on port 3000; API on port 8080
    • yarn dev:ui: Start Storyboook app on port 3000

Environment Variables

All required environment variables are documented in the package.json of each project, under the required-env field.

Vercel supports adding environment variables for Development, Preview, and Production environments. A set of Vercel system environemnt variables can also be exposed for each project.

For more information, see Environment Variables from the Vercel docs.

Coding Standards

Husky is used to enforce coding and commit message standards.

Branch Naming Conventions

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.

Commit Messages

This project follows 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

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 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.

Getting Help

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.

Creating a Pull Request

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