Monorepo with ESLint packages

[arcticicestudio]

Current Project State

Currently this repository only contains the actual styleguide documentation while specific projects that implement the guidelines for linters and code style analyzer live in separate repositories. This is the best approach for modularity and a small and clear code base, but it increases the maintenance overhead by 1(n) since changes to the development workflow or toolbox, general project documentations as well as dependency management requires changes in every repository with dedicated tickets/issues and PRs. In particular, Node packages require frequent dependency management due to their fast development cycles to keep up-to-date with the latest package changes like (security) bug fixes.

This styleguide is currently implemented by the eslint-config-arcticicestudio-base and eslint-config-arcticicestudio Node packages living in their own repositories. The development workflow is clean using most of GitHub's awesome features like project boards, codeowner assignments, issue & PR automation and so on, but changes to one of them often requires actions for the other package too since they are based on each other and they are using the same development tooling and documentation standards.

Monorepo Comparison

Monorepos are a fantastic way to manage such a project structure, but there are also some points that must be taken into account:

• No more scoped code — the developer experience with Git is slightly worse because commits can contains changes to multiple scopes of the code. Since there is only a “transparent separation” of code, that was previously located in a dedicated repository but is not aggregated into a parent (e.g. packages) with other modules, commits can now contain changes to multiple code scopes spread over the entire code base.
• No more assignment of commits to single modules — like described in the bullet point above, commit can contain changes to multiple modules, it is harder to detect which commit targeted a specific module.
• Steeper learning curve for new contributors — in a dedicated repository that only hosts a specific module it is easier for new developers to contribute to the project, but in a monorepo they might need to change code in multiple places within other modules or the root code/documentation of the entire project.
• Uniform version number — in order to keep conform to SemVer, the entire project must use a uniform version number. This means that a module that has not been changed since the last version must also be incremented in order to keep compatible with the other modules.
  Using different version numbers prefixed/suffixed with an individual version number is a not an option, increases the maintenance overhead and and drastically reduces the project overview and quality! This would result in multiple Git tags on the main branch as well as “empty” changelogs and release notes with placeholder logs that only refer to changes of other modules.

Project Future

Even though a monorepo requires some special thoughts, it also comes with a lot of benefits and makes sense for specific project modules that are slightly coupled and where using dedicated repositories only increases the maintenance overhead when changes must be reflected in multiple modules anyway.

In order to reduce the maintenance overhead both Node packages, eslint-config-arcticicestudio-base and eslint-config-arcticicestudio, will be migrated into this repository by adapting to Yarn workspaces. This simplifies the development tooling setup and allows to use a unified documentation base as well as a smoother development and testing workflow.

This change also implies that the root of the repository will be the main package for the entire project setup including shared development dependencies, tools and documentations while the packages will only contain specific configurations and (dev)dependencies.

Scoped Packages

Currently eslint-config-arcticicestudio-base and eslint-config-arcticicestudio are no scoped packages but suffixed with -arcticicestudio*. To simplify the naming and improving the usage of user/organization specific packages both packages will be scoped to @arcticicestudio resulting in the new names @arcticicestudio/eslint-config-base and @arcticicestudio/eslint-config. They can be used through ESLint's support for shared configuration with scoped packages.
The currently released public versions will be deprecated using the npm deprecate command where the provided message will point out to migrate to the new scoped packages.

Versioning

The style guide itself and all packages will use a shared/fixed/locked version. This helps all packages to keep in sync and ensure the compatibility with the latest style guide version.

Standard Setup

In order to keep up-to-date with the latest project setup for all Arctic Ice Studio projects, the tools and documentations will be integrated and updated through the following tickets:

• Git ignore and attribute pattern #9 (⊶ 8e99240) „Git ignore and attribute pattern“ — completed ✓
• Git mail mapping #10 (⊶ db2a43b) „Git mail mapping“ — completed ✓
• Prettier #11 (⊶ 1025324) „Prettier“ — completed ✓
• lint-staged #12 (⊶ c21a58a) „lint-staged“ — completed ✓
• Husky #13 (⊶ b4cac34) „Husky“ — completed ✓
• General repository and package documentations and metadata #14 (⊶ be122b1) „General repository and package documentations and metadata“ — completed ✓
• GitHub issue and pull request templates #15 (⊶ c25d1ef) „GitHub issue and pull request templates“ — completed ✓