Developer Guidelines

Dev Setup

• Use yarn
• look at the .node-version to see which node to use or even better, use nodenv

The project is monorepo. It uses Yarn Workspaces for bootstrapping the project and lerna for publishing.

Language Flavour

ES2015 flavored for React development with export syntax extensions is used in Skele packages. In Babel terms, this is:

    {
      "presets": ["react-native"]
    }

Imports and Exports

ES6 Modules are used for module definitions.

export default is used only when a module has a single meaningful thing to export (e.g. a Class); otherwise named exports are used.

Within a package

• importing is done using relative paths, directly referring to the module in question.

Public API of a package

The only visible (i.e. import-able) parts of a package are its exports from the package's main module. It is not allowed to import a module from another package using a direct file reference. i.e.

import {ui} from '@skele/core'; // ok
import ui from '@skele/core/ui'; // not ok
import X from './elements/x'; // ok, within Skele

Versioning and Branches

We use semantic versioning 2.0.

• The master branch is "latest"
• We use pull requests (except for trivial changes) to change the master branch

Commit messages; reviewing and merging PRs and the Release log

We use conventional-github-releaser with the angular convention to manage our releases on GitHub. This means that release notes are generated out of the content of our commit messages. We need to take some care of them in order to have valid release notes.

Specifically, this means:

• when developing

  • use commit messages as you please
  • create a pull pull request
    • In the title of the pull request use the angular convention in the title
    • describe nicely what you are doing and why in the body. We need these for further reference/
  • do one PR per significant change (which you can describe in the PR title)

• when reviewing and merging

  • The merge commit title should follow the angular convention and also contain a reference to the pull request in braces -- e.g. (#8) -- this is done automatically for you by github.
  • Copy the description of the pull request into the merge
  • Decide whether you want to
    • squash the PR into a single commit -- do this for smaller PR where it makes no sense to keep all commits around
    • do a normal merge -- do this when the PR is a bigger change and the commits make sense on their own