-
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Monorepo with ESLint packages #16
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
svengreb
requested changes
Aug 19, 2019
>> 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 implemented by the `eslint-config-arcticicestudio-base` (1) and `eslint-config-arcticicestudio (2) 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 (3) 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 (3) 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 (4), 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 section 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, `eslint-config-arcticicestudio-base` (1) and `eslint-config-arcticicestudio` (2), have been migrated into this repository by adapting to Yarn workspaces (5) since they are slightly and 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 contain specific configurations and (dev)dependencies. >>> Scoped Packages Previously `eslint-config-arcticicestudio-base` (1) and `eslint-config-arcticicestudio` (2) were no scoped packages (6) 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 package names `@arcticicestudio/eslint-config-base` and `@arcticicestudio/eslint-config`. They can be used through ESLint's support for shared configuration with scoped packages (7). The previously released public versions have been deprecated using the `npm deprecate` command (8) where the provided message points out to migrate to the new scoped packages. >>> Versioning The style guide itself and all packages now 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 have been integrated and updated through the following tickets: - GH-9 (8e99240) "Git ignore and attribute pattern" - GH-10 (db2a43b) "Git mail mapping" - GH-11 (1025324) "Prettier" - GH-12 (c21a58a) "lint-staged" - GH-13 (b4cac34) "Husky" - GH-14 (be122b1) "General repository and package documentations and metadata" - GH-15 (c25d1ef) "GitHub issue and pull request templates" References: (1) https://www.npmjs.com/package/eslint-config-arcticicestudio-base (2) https://www.npmjs.com/package/eslint-config-arcticicestudio (3) https://trunkbaseddevelopment.com/monorepos/ (4) https://semver.org (5) https://yarnpkg.com/en/docs/workspaces (6) https://docs.npmjs.com/about-scopes (7) https://eslint.org/docs/developer-guide/shareable-configs#npm-scoped-modules (8) https://docs.npmjs.com/cli/deprecate Epic: GH-8 GH-8
arcticicestudio
force-pushed
the
epic/gh-8-monorepo-eslint-pkgs
branch
from
August 19, 2019 17:58
f30ec45
to
31bcf3d
Compare
svengreb
approved these changes
Aug 19, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #8