React

Specific configuration for React apps.

See: https://github.com/strvcom/code-quality-tools/tree/master/packages/eslint-config-react

React Native

Specific configuration for React Native apps.

See: https://github.com/strvcom/code-quality-tools/tree/master/packages/eslint-config-react-native

Automate release generation using conventional changelog and semantic release.

• https://semantic-release.gitbook.io/semantic-release/

• https://github.com/semantic-release/semantic-release/releases/tag/v19.0.2

• https://github.com/semantic-release/semantic-release/tree/master/.github/workflows

• https://github.com/semantic-release/github

• https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases

• https://www.npmjs.com/package/conventional-github-releaser

• https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog-conventionalcommits/writer-opts.js

• https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-conventionalcommits

• https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-cli#quick-start

• https://github.com/conventional-changelog/standard-version/tree/f579ff08f386aaae022a395ed0dbec9af77a5d49/lib

• https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog-cli/README.md

• https://github.com/conventional-changelog/conventional-changelog-config-spec/blob/master/versions/2.1.0/README.md

ESLint

We should be able to lint our javascript projects through ESLint and its configuration.

Base

Base configuration which should be used everywhere.

See: https://github.com/strvcom/code-quality-tools/tree/master/packages/eslint-config-base

Maintaining a custom config like this is not easy, especially in the long run.

How about moving to a community-maintained config?

Benefits

1. Less time spent on dev stack, more time on coding.
2. A well-tested config means less bugs and pitfalls in the config itself.
3. Using something close to a community standard improves interoperability and helps new developers read and understand the code more quickly.

Proposal

• remove current default config
• add stylelint-config-standard for plain CSS (is it necessary at all?)
• add stylelint-config-standard-scss for SCSS
• keep optional config defining properties order

A quick test in spirit-web resulted in this project-specific .stylelintrc config:

{
  "extends": [
    "stylelint-config-standard-scss",
    "@lmc-eu/stylelint-config/optional"
  ],
  "rules": {
    "indentation": 4,
    "selector-class-pattern": [
      "^lmc-([A-Z][a-zA-Z0-9]*)((--|__)[a-z0-9]+)*$",
      {
        "message": "Expected class selector to be in format `lmc-MyComponent__element`, `lmc-MyComponent--modifier`"
      }
    ]
  }
}

Violated rules were: indentation (we had 4 spaces instead of 2), string-quotes (single quotes were used instead of double quotes), scss/dollar-variable-empty-line-before (blank lines between Sass variable groups needed to be removed), and selector-class-pattern (kebab case against our SUIT CSS naming convention). I kept our indentation, specified custom selector-class-pattern, and gave in to the other rules. But anything may be changed the way we want it.

To be fair, more tests on larger code bases may be necessary to see a bigger picture.

Extending

If we need more strict rules, our config can be extended as we wish in the future. The point is that most of the settings will already be there.

https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-conventionalcommits

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Cannot find preset's package (@lmc-eu)

https://github.com/conventional-changelog/conventional-changelog/pull/974/files

camelcase rule

allow: ['^UNSAFE_']

EditorConfig

We should be able to create a default template but since EditorConfig does not support any kind of module system it will probably be difficult to distribute this as a package and we will likely have to resort to just copying a pre-made file into projects via the aforementioned CLI tool.

https://github.com/ota-meshi/eslint-plugin-regexp

lmc-eu/spirit-design-system#130 (comment)

Remove blank line from top of the header template.

See: lmc-eu/cookie-consent-manager#5

https://turborepo.org/docs/guides/migrate-from-lerna

Commitlint-config has prod-dependency on @lmc-eu/conventional-changelog-lmc-bitbucket - see https://github.com/lmc-eu/code-quality-tools/blob/main/packages/commitlint-config/package.json#L26

Why is this needed? In https://github.com/lmc-eu/cookie-consent-manager we don't use @lmc-eu/conventional-changelog-lmc-bitbucket but @lmc-eu/conventional-changelog-lmc-github instead, but we still gets this (unused?) dependency installed.

The BREAKING CHANGES commits are missing from the generated changelog when using @lmc-eu/conventional-changelog-lmc-github.

Which is quite unfortunate :)

BREAKING CHANGE is only allowed conventional commit

https://www.conventionalcommits.org/en/v1.0.0/

Lerna uses conventional commits to parse and generate changelog. But BREAKING CHANGES commit is not recognized.

When using commit lint, scopes on the beginning of each commit message are enforced. However, there is nowhere any documentation which scopes should be used and when.
There is only configuration file, but without further documentation. This is very bad experience for people without previous conventional commits knowledge.

There should be a clear documentation of the scopes, similarly as commitzen provide:

(Or - we should preferably just use some common naming scheme, with slightest changes possible, and not invent our own.)

• gajus/eslint-plugin-jsdoc#847
• https://stackoverflow.com/questions/76112563/definition-for-rule-jsdoc-newline-after-description-was-not-found-jsdoc-newline
• gajus/eslint-plugin-jsdoc#1031
• https://github.com/gajus/eslint-plugin-jsdoc/releases/tag/v42.0.0

We want to preserve the new line after the description when using the JSDoc comment.

GraphQL

Specific configuration for apps using GraphQL.

ESLint Plugin GraphQL is great candidate.
GraphQL ESLint plugin

See: https://github.com/strvcom/code-quality-tools/tree/master/packages/eslint-config-graphql

https://github.com/lmc-eu/code-quality-tools/pull/44/files#r781558974

## [1.0.1](https://github.com/lmc-eu/code-quality-tools/compare/@lmc-eu/[email protected]...@lmc-eu/[email protected]) (2021-12-18)

Maybe the tag should be linked to github release instead of diff.
But this is standard behavior in conventional-changelogs.

Maybe we can find another place where we can use it.

CLI tool

Create a CLI of some sorts to allow generating configuration for all the tools supported through this monorepo into a project. Currently, people have to manually install the packages and create the configs by hand.

Yeoman is a great candidate for this.

Jest

Specific configuration for Jest testing.

ESLint Plugin Jest is great candidate.

• https://prettier.io/blog/2022/03/16/2.6.0.html
• prettier/prettier#6644
• https://deploy-preview-6644--prettier.netlify.app/playground/

Textlint

We should be able to lint our written documentation.

Textlint is great candidate.

See: https://github.com/strvcom/code-quality-tools/tree/master/packages/textlint-rule-preset-strv

Typescript

Specific configuration for apps using Typescript.

https://github.com/strvcom/code-quality-tools/tree/master/packages/eslint-config-typescript

Prettier prefers:

margin-bottom: tools.rem2em(
    tokens.$space-6,
    tools.rem2em(tokens.$heading-small-desktop)
);

Stylelint prefers:

margin-bottom: tools.rem2em(tokens.$space-6, tools.rem2em(tokens.$heading-small-desktop));

This does not work either:

margin-bottom:
    tools.rem2em(
        tokens.$space-6,
        tools.rem2em(tokens.$heading-small-desktop)
    );

Workaround: disable either Stylelint or Prettier for that line / code block.

It seems there might be a conflict of declaration-colon-space-after and declaration-colon-newline-after Stylelint rules.

Markdown

We should be able lint and format our readmes and other markdown documentation.

Remark CLI is great candidate.

@adamkudrna If linting is all we need, I have quite a good experience with https://github.com/DavidAnson/markdownlint-cli2 (compatible with MDX, to certain extent).

See: https://github.com/strvcom/code-quality-tools/tree/master/packages/remark-config

Node

Specific configuration for Node.js backends.

See: https://github.com/strvcom/code-quality-tools/tree/master/packages/eslint-config-node

prettier/prettier#4251