This is an internal documentation. There is a good chance you’re looking for something else. See Disclaimer.

Contribute

Hint

See Contributing Guidelines for guidelines relating to the actual code, this is more about how to contribute to client repo.

Code Style Plugins

ESlint

Most code styles are enforced by ESLint. The gitlab build will fail if not every ESlint rule is fulfilled. Active ESlint rules can be seen here: https://gitlab.com/toccoag/tocco-client/blob/master/.eslintrc

To show current linting errors and warnings:

yarn lint

To try auto-fix them:

yarn lint:fix

Note

ESLint command will run as a git pre commit hook. It isn’t possible to commit anything as long as there are linting errors. Lint will also be executed automatically on our CI.

Setup Linting with IntelliJ

  • Install ESLint Plugin

  • Settings (Preferences on OS X) | Languages & Frameworks | JavaScript | Code Quality Tools –enable

  • Settings (Preferences on OS X) | Editor | Inspections | Code Style Issues | Unterminated statement – disable

Setup Linting with Visual Studio Code

  • Install ESLint Plugin

Prettier

Prettier is used as a code formatter tool.

To format the project with prettier:

yarn format

Setup Formatting with IntelliJ

  • Install Prettier Plugin

  • Settings (Preferences on OS X) | Languages & Frameworks | JavaScript | Prettier -> set package

  • Settings (Preferences on OS X) | Languages & Frameworks | JavaScript | Prettier -> enable for reformat code

Setup Formatting with Visual Studio Code

  • Install Prettier Plugin

  • Set Prettier as Default Formatter

Note

Prettier command will run as a git pre commit hook. It isn’t possible to commit anything as long as there are formatting errors. Prettier will also be executed automatically on our CI.

Changelog

See Client changelog

Maintaining older versions

Older Nice versions are using older releases of client packages. If a critical bug is found in an older package we need to fix it in that version. It’s not possible to just fix the bug in master an install the newest package since that could lead to compatibility problems. For example if the REST endpoint changes. Furthermore we don’t want to deploy all new features with the bug fix.

For each Nice release there is a release branch in the tocco-client repository. These release branches are protected and require commits to be submitted via a merge request.

Warning

Release branches have to be created parallel to the Nice releases and have to be used strictly!

Bug fixing

So if a bug is found, let’s say in Nice version 2.17, we have to fix this bug in 2.17, 2.18, … and master. Assumed it’s a critical bug, otherwise it will just be fixed in master with a merge request branch.

  1. Find out the oldest yet supported version of Nice that contains the package with the bug.

  2. Create a fix branch based on the release branch (e.g. git checkout -b pr/217/bug nice-releases/217)

  3. Commit fix to branch. Preferably with a regression test to verify the fix. (Add Cherry-pick: Up to the commit message body as Refs: TOCDEV-1 (parsing is case insensitive and whitespaces are ignored but hyphen and semicolon are required) that the commit is automatically cherry picked and released in the versions 2.18 - master)

  4. Create a merge request, wait until approved and rebase into release branch.

  5. Release branch will be automatically published overnight. (Changelog: has to be in the commit message body.)

  6. Delete fix branch.

  7. If the commit was annotated with Cherry-pick: Up, the CI will automatically pick this commit in the next version and will release the packages accordingly. See CI page for more information.

There is still the possibility to do things manually without the cherry-pick annotation. In this case the relevant commits should be cherry picked with git in the next version. Then the packages can be published there as well. Repeat until hotfix is no more relevant or the bug is fixed in the newest version (master).

Naming

what

schema

example

Release Branch

nice-releases/niceversion

nice-releases/217

Fix Branch

pr/niceversion/descr

pr/217/image-bug

Hotfix Release

currentversion-hotfixVersion.HotFixNumber

1.0.2-hotfix217.2

Release Tag

niceVersion

nice215

Example

../../_images/release_branching.png

Bug fix release Example (Created with draw.io, source xml in resource folder)

This examples shows two packages (Merge and Login) each with an individual release since they are both tocco-apps.

Performed actions:

  • Minor releases in master branch (feature branch are not show in diagram)

  • Bug fix with fix branches in older version of Nice.

  • Npm Tags (latest tags of master releases not shown).

The cherry-pick shown in the example can either be done manually or is done automatically with the commit annotation.

Interactive Rebasing

An interactive rebase is recommended if the base should be updated to enable a rebase. This also gives the change to adjust commit messages, amend changes to an existing commit or clean up the commit history of a change in general. If for example a merge request review suggest a change to a commit that is not the last one, with an interactive rebase the commit can be edited to ensure a clean history.

A remote identical to origin named “tocco-client” must exists for the following commands.

git fetch tocco-client
git merge-base my-branch tocco-client/master
git rebase -i ${HASH}
git rebase tocco-client/master
git push -f

Of course when working on a branch based on a nice-release branch tocco-client/master must be replaced accordingly.