development.md

Development

A guide for adding code to this project.

• Development
  • Installation
  • Development Workflow
  • Tests
  • Committing Code
    • General Rules
    • Commit Messages
  • Design
  • Technologies Used

Installation

Follow the installation guide.

Development Workflow

• This project uses git-flow. For an in-depth overview of git-flow, read "A successful Git branching model".
• Let's stop saying Master/Slave

As a person contributing code but not creating production releases (this is most people!), here's what you need to know:

• The default branch is develop. All pull requests should be made to this branch. It should be stable, and all commits are visible at a staging server.
• When working on a bug or feature, you should branch from the develop branch. When you're done, you should open a pull request from your feature branch to develop.
• The release branch is the live production branch, and is the code deployed to editor.p5js.org. Changes to this branch should be made carefully, and will be done using git tags.
• Emergency hotfix changes should be branched from release and merged via a pull request to release. After a PR is merged, then the commits can be merged to develop.

See the release guide for information about creating a release.

Tests

To run the test suite simply run npm test (after installing dependencies with npm install)

A sample unit test could be found here: Nav.test.jsx.

Committing Code

Inspired by Git/GitHub commit standards & conventions.

Good commit messages serve at least three important purposes:

• They speed up the reviewing process.
• They help us write good release notes.
• They help future maintainers understand your change and the reasons behind it.

General Rules

• Make atomic commits of changes, even across multiple files, in logical units. That is, as much as possible, each commit should be focused on one specific purpose.
• As much as possible, make sure a commit does not contain unnecessary whitespace changes. This can be checked as follows:

$ git diff --check

Commit Messages

Structure your commit message like this:

[#issueid] Short (50 chars or less) summary of changes

More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together.

Further paragraphs come after blank lines.

  - Bullet points are okay, too

  - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here

• Write the summary line and description of what you have done in the imperative mode, that is as if you were commanding someone. Start the line with "Fix", "Add", "Change" instead of "Fixed", "Added", "Changed".
• Link the GitHub issue you are working on in the summary line in brackets, e.g. [#123]
• Always leave the second line blank.
• Be as descriptive as possible in the description. It helps reasoning about the intention of commits and gives more context about why changes happened.
• If it seems difficult to summarize what your commit does, it may be because it includes several logical changes or bug fixes, and are better split up into several commits using git add -p.
• Note that you can connect multiple issues to a commit, if necessary: [#123][#456] Add Button component

Design

• Style Guide/Design System on Figma
• Latest Design on Figma. Note that the current design on the website has diverged, parts of this design will not be implemented, but it is still helpful to have around for reference.
• Mobile Designs, Responsive Designs

Technologies Used

MERN stack - MongoDB, Express, React/Redux, and Node.

• For a reference to the file structure format this project is using, please look at the Mern Starter.

• This project does not use CSS Modules, styled-components, or other CSS-in-JS libraries, but uses Sass. BEM guidelines and naming conventions are followed.

• For common and reusable styles, write OOSCSS (Object-Oriented SCSS) with placeholders and mixins. For organizing styles, follow the 7-1 Pattern for Sass.

• We're using ES6 and transpiling to ES5 using Babel.

• For reference to the JavaScript style guide, see the Airbnb Style Guide, React ESLint Plugin.

• The ESLint configuration is based on a few popular React/Redux boilerplates. Open to suggestions on this. If in development, you're getting annoyed with ESLint, you can disable any line from eslint by commenting at the end of the line // eslint-disable-line.

• Jest for unit tests and snapshot testing along with Enzyme for testing React.