conventions.adoc

CSS and SCSS variables naming conventions

The elements, components and areas SCSS variables should at best follow this pattern, seperated by dashes:

element variant state property

e.g.

--element---property: value;
--element--state-property: value;
--element-variant--property: value;
--element-variant-state-property: value;

Git commits conventions

We’re using husky git hooks in combination with commitlint according to https://commitlint.js.org/#/concepts-commit-conventions:

type(scope?): subject
body?
footer?

Type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum]

— commitlint documentation
Source: https://commitlint.js.org/#/?id=test

If you’d like to test your commit message previous to using it, you could test it on the command line:

echo 'foo: bar' | commitlint

Code conventions

The general code conventions are guaranteed by the following tools.

Through configuration files: .editorconfig for IDEs and .gitattributes for git checkins

Both the .editorconfig and .gitattributes ensure a consistent code structure and conventions through their configurations.

xo

The xo tool provides a general code linting mechanism.

prettier

The prettier tool provides a general code prettfying.

Linting via [Super-Linter](https://github.com/marketplace/actions/super-linter)

To prevent the linting of generated files (like e.g. the reference screenshots by backstopjs), we’ll be excluding those via an environmental GitHub variable for this project with the env FILTER_REGEX_EXCLUDE.

Further links regarding language specific settings are located in the super-lint repository: https://github.com/github/super-linter/tree/master/TEMPLATES

json files via jsonlint

• pipeline-components.dev/containers/jsonlint

yaml files via yamllint

• yamllint.readthedocs.io

markdown files via markdownlint

• github.com/markdownlint/markdownlint

shell scripts via ShellCheck

• github.com/koalaman/shellcheck