Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Prettier #11

Closed
6 tasks done
arcticicestudio opened this issue Aug 15, 2019 · 0 comments
Closed
6 tasks done

Prettier #11

arcticicestudio opened this issue Aug 15, 2019 · 0 comments
Labels
context-workflow scope-dx scope-maintainability scope-quality type-feature
Milestone
0.7.0

Comments

@arcticicestudio
Copy link
Contributor

arcticicestudio commented Aug 15, 2019 •
edited
Loading

Epic: #8

Integrate 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.

Configuration

This is one of the main features of Prettier: It already provides the best and recommended style configurations of-out-the-box™.
The only option we will change is the print width. It is set to 80 by default which not up-to-date for modern screens (might only be relevant when working in terminals only like e.g. with Vim). It'll be changed to 120 used by all of Arctic Ice Studio's style guides.
The prettier.config.js configuration file will be placed in the project root as well as the .prettierignore file to also define ignore pattern.

NPM script/task

To allow to format all sources a format:pretty npm script/task will be added to be included in the main format script flow.

False-Positives

To ensure incorrect examples of the style guide won't be fixed by Prettier, the affected lines must be excluded from Prettier by adding the <!-- prettier-ignore --> handle for HTML.
Note that this might trigger remark-lint when added right above a code block (no-missing-blank-lines). This can also be fixed by adding the <!--lint disable no-missing-blank-lines--> handle as well.

Tasks

  • Install prettier packages.
  • Implement prettier.config.js configuration file.
  • Implement .prettierignore ignore pattern file.
  • Implement NPM format:pretty script/task.
  • Format current code base for the first time and fix possible style guide violations using the configured linters of the project.
  • Ensure compatibility with Prettier (Prettier #11) by adding required ignore/disable handles for Prettier and remark-lint.
@arcticicestudio arcticicestudio added this to the Next milestone Aug 15, 2019
@arcticicestudio arcticicestudio self-assigned this Aug 15, 2019
@arcticicestudio arcticicestudio mentioned this issue Aug 15, 2019
Closed
2 tasks
arcticicestudio added a commit that referenced this issue Aug 15, 2019
@arcticicestudio
lint-staged
c21a58a 
Integrated "lint-staged" (1) to run linters against staged Git files to
prevent to add code that violates any style guide into the code base.

>>> Configuration

The configuration file `lint-staged.config.js` is placed in the project
root and includes the command that should be run for matching file
extensions (globs). It will include at least the three following entries
with the same order as listed here:

1. `prettier --list-different` - Run Prettier (GH-11) against
   `*.{js,json,yml}` to ensure all files are formatted correctly.
   The `--list-different` prints the found files that are not conform to
   the Prettier configuration.
2. `eslint` - Run ESLint against `*.{js}` to ensure all JavaScript files
   are compliant to the style guide after being formatted with Prettier.
3. `remark --no-stdout` - Run remark-lint against `*.md` to ensure all
   Markdown files are compliant to the style guide.
   The `--no-stdout` flag suppresses the output of the parsed file
   content.

References:
  (1) https://github.com/okonet/lint-staged

Epic: GH-8
Must be resolved after GH-11
Resolves GH-12
@arcticicestudio arcticicestudio removed their assignment Aug 15, 2019
@arcticicestudio arcticicestudio mentioned this issue Aug 19, 2019
Closed
arcticicestudio added a commit that referenced this issue Aug 19, 2019
@arcticicestudio
Monorepo with ESLint packages
f30ec45 
>> 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 added a commit that referenced this issue Aug 19, 2019
@arcticicestudio
Monorepo with ESLint packages
31bcf3d 
>> 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 added a commit that referenced this issue Aug 19, 2019
@arcticicestudio
Monorepo with ESLint packages (#16)
ac611f7 
>> 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
Resolves GH-8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
context-workflow scope-dx scope-maintainability scope-quality type-feature
Projects
None yet
Milestone
0.7.0
Development

No branches or pull requests
1 participant
@arcticicestudio