0.7.0

Epics

Monorepo with ESLint packages — #8 ⇄ #16 (⊶ ac611f7)
↠ Resolved the epic by converting the repository into a monorepo and migrating the @arcticicestudio/eslint-config (previously eslint-config-arcticicestudio) + @arcticicestudio/eslint-config-base (previously eslint-config-arcticicestudio-base) packages!

Previous Project State

Previously this repository only contained the actual styleguide documentation while specific projects that implement the guidelines for linters and code style analyzer lived in separate repositories. This was the best approach for modularity and a small and clear code base, but it increased the maintenance overhead by 1(n) since changes to the development workflow or toolbox, general project documentations as well as dependency management required 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 @arcticicestudio/eslint-config (previously eslint-config-arcticicestudio) and @arcticicestudio/eslint-config-base (previously eslint-config-arcticicestudio-base) Node packages that lived in their own repositories. The development workflow was 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 required 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

Actually I'm not a supporter when it comes to monorepos and next to the advantages a monorepo also comes with disadvantages:

• No more scoped code — The developer experience with Git is clearly worse because commits can contains changes to multiple scopes of the code. Since there are 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 go, increases the maintenance overhead and and drastically reduces the project overview and quality! This would result in multiple Git tags on the master branch as well as “empty” changelogs and release notes with placeholder logs that only refer to changes of other modules.

Project Future

Even though there are disadvantages (see above), a monorepo makes sense only for specific project modules thar 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, @arcticicestudio/eslint-config (previously eslint-config-arcticicestudio) and @arcticicestudio/eslint-config-base (previously eslint-config-arcticicestudio-base), have been migrated into this repository by adapting to Yarn workspaces since they are slightly dependent on each other anyway. 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 is now the main package for the entire project setup including shared development dependencies, tools and documentations while the packages only contains specific configurations and (dev)dependencies.

Scoped Packages

The previous eslint-config-arcticicestudio and eslint-config-arcticicestudio-base packages were no scoped packages but suffixed with -arcticicestudio*. To simplify the naming and improving the usage of user/organization specific packages both packages are now 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 previously released public versions have been deprecated using the npm deprecate command where the provided message points out to migrate to the new scoped packages.

Versioning

The style guide itself and all packages using 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 have been integrated and updated through the following tickets:

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

Features

GitHub issue and pull request templates — #15 (⊶ c25d1ef)
↠ Integrated GitHub's feature to define multiple issue templates while the initial template file is used as a fallback/generic template to link to the specific ones.

Read the GitHub Help article for more details about issue and pull request templates. Also check out how to manually create issue templates, a pull request template. and the guide on how to create the (deprecated) fallback/generic issue template.

Improvements

General repository and package documentations and metadata — #14 (⊶ be122b1)
↠ The previous project repository documentations were not designed for a monorepo layout and have been be updated including various badges provided by the great shields.io project.

Further documentations about the project architecture and technologies as well as guides for contributions to develop, run and maintain the project stayed within the packages itself.
There are also various places that contained outdated documentations and metadata that have been updated too.

See #14 for more details about what exactly has been updated.

Tasks

Introducing remark-lint — #5 ⇄ #6 (⊶ fa9af09)
↠ Integrated remark-lint, a linter built on remark, the powerful Markdown processor powered by plugins such as remark-lint.
It is used through remark-cli with remark-preset-lint-arcticicestudio, the custom preset that implements the Arctic ice Studio Markdown Style Guide.

To lint all Markdown sources within the project the lint:md NPM script has been added that will be picked up by the main lint script.

Documentation for official ESLint extensible shared configurations — #7 (⊶ 57b8ce0)
↠ Added information about the official @arcticicestudio/eslint-config and @arcticicestudio/eslint-config-base extensible shared configurations for ESLint to the documentation.

Git ignore and attribute pattern — #9 (⊶ 8e99240)
↠ Added the .gitattributes and .gitignore configuration files to define the pattern.

Git mail mapping — #10 (⊶ db2a43b)
↠ Added a Git mailmap file to link to in documentations and allow contributors to send mails regarding security issues. This prevents unnecessary overhead of updating all documents when new core team and members and contributors are added and additionally adds the main functionality of the file: Mapping commits when someone uses a different email address.

Introducing Prettier — #11 (⊶ 1025324)
↠ Integrated Prettier, the opinionated code formatter with support for many languages and integrations with most editors. It ensures that all outputted code conforms to a consistent style and provides the best and recommended style configurations of-out-the-box™.
Read #11 for more details about the configuration and setup as well as included plugins.

To format all compatible sources within the project the format:pretty NPM script has been added that will be picked up by the main format script.

Introducing lint-staged — #12 (⊶ c21a58a)
↠ Integrated lint-staged to run linters against staged Git files and prevent adding code that violates any style guide into the code base.

Read #12 for more details about the configuration and setup.

Introducing Husky — #13 (⊶ b4cac34)
↠ Integrated Husky, the tool that make Git hooks easy and can prevent bad Git commits, pushes and more woof!

Read #13 for more details about the configuration and setup.

The full changelog is available in the repository

Copyright © 2016-present Sven Greb