frontend-coding-standards
frontend-coding-standards copied to clipboard
Media.Monks - Frontend Coding Standards
When I write a nice color in code like `0xFF0000`, prettier converts this to `0xff_00_00`. This is inconvenient because you can't copy this value back to photoshop or somewhere else...
Another possible branch prefix name is `hotfix`. These are branched from the `main` branch. _Originally posted by @ThijsTyZ in https://github.com/mediamonks/frontend-coding-standards/pull/69#discussion_r588341435_
**CSS Section -> Selectors are placed on separate lines:** ``` /* Good */ h1, h2, h3 { text-transform: uppercase; } /* Bad */ h1, h2, h3 { text-transform: uppercase; }...
At the moment we have different casing for "Globally used constants", see https://github.com/mediamonks/frontend-coding-standards#globally-used-constants This rule got introduced back in the days when we only had `var` and there was no...
This uses the default tsconfig.json generated with tsc --init (tsc Version 3.9.5). Only change from that right now is adding `"importsNotUsedAsValues": "error"`
For styling there is a preference for using the `ms` as a unit and value instead of `s`. This needs to be reflected in the coding standards and linting
We should run the `generate-table-of-contents` and `format` script so that the files in this repository are automatically updated and formatted to avoid conflicts and keep consistency. We can use `husky`...
Hello everyone! Do we have any rules for how we write css properties inside selectors? I've heard about some practices where CSS properties are grouped according to some [semantic criteria](https://github.com/constverum/stylelint-config-rational-order)...
Some of our tools, such as [transition-component](https://github.com/mediamonks/transition-component) and [muban](https://github.com/mubanjs/muban) have their docs in separate `.md` files that are then bundled into a github pages website using [vupress](https://vuepress.vuejs.org/), see: * https://mediamonks.github.io/transition-component/...