-
-
Notifications
You must be signed in to change notification settings - Fork 24
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
Merge pull request #21 from arcticicestudio/feature/gh-16-prettier Integrated Prettier (1), 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 (2). 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 is now set to changed to 120 used by all of Arctic Ice Studio's style guides. The `prettier.config.js` configuration file is placed in the project root as well as the `.prettierignore` file to also define ignore pattern. >> ESLint Compatibility To be fully compatible with ESLint (implemented in #15), eslint-plugin-prettier (3) has been included and added to the `plugins` array of the ESLint configuration (4). To enable full compatibility the `prettier/prettier` rule must be added with the `error` level. >> NPM script/task To allow to format all sources a `format:pretty` npm script/task has been added to be included in the main `format` script flow later on. >> Initial Formatting Afterwards Prettier has been run on the current code base Format and fixed found style guide violations using the configured linters. References: (1) https://prettier.io (2) https://prettier.io/docs/en/options.html#print-width (3) https://github.com/prettier/eslint-plugin-prettier (4) https://eslint.org/docs/user-guide/configuring#configuring-plugins
- Loading branch information
Showing
9 changed files
with
109 additions
and
47 deletions.
There are no files selected for viewing
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
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
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
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
# Copyright (C) 2018-present Arctic Ice Studio <[email protected]> | ||
# Copyright (C) 2018-present Sven Greb <[email protected]> | ||
# | ||
# Project: Nord Docs | ||
# Repository: https://github.com/arcticicestudio/nord-docs | ||
# License: MIT | ||
|
||
.cache/* | ||
build/* | ||
**/node_modules/* | ||
public/* | ||
static/* |
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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -25,7 +25,7 @@ Contributions related to a [Nord port project][gh-profile-repo-search] belong to | |
|
||
### Bug Reports | ||
|
||
A bug is a *demonstrable problem* that is caused by the code in the repository. This section guides you through submitting a bug report for Nord. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior and find related reports. | ||
A bug is a _demonstrable problem_ that is caused by the code in the repository. This section guides you through submitting a bug report for Nord. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior and find related reports. | ||
|
||
**Do NOT report security vulnerabilities in public issues!** Please only contact one of the core team members or project owner in a responsible manner by [email][gh-mailmap] or via [email protected]. We will assess the issue as soon as possible on a best-effort basis and will give you an estimate for when we have a fix and release available for an eventual public disclosure. | ||
|
||
|
@@ -100,7 +100,7 @@ Nord uses the [gitflow][gitflow] branching model. The repository consists of two | |
- `master` - The source code of `HEAD` always reflects a tagged release version. | ||
- `develop` - The default branch where the source code of `HEAD` always reflects a state with the latest development state. | ||
|
||
**All [pull requests](#pull-requests) for the limited development lifecycle *story*/*topic* branches must be send against the `develop` branch**. | ||
**All [pull requests](#pull-requests) for the limited development lifecycle _story_/_topic_ branches must be send against the `develop` branch**. | ||
|
||
<!-- lint disable no-heading-punctuation --> | ||
|
||
|
@@ -138,7 +138,7 @@ Nord adheres to the [Arctic Ice Studio Markdown Style Guide][gh-styleguide-markd | |
|
||
### Git Commit Messages | ||
|
||
A well-crafted Git commit message is the best way to communicate *context* about a change to the maintainers. The code will tell what changed, but only the commit message can properly tell why. Re-establishing the context of a piece of code is wasteful. We can't avoid it completely, so our efforts should go to reducing it as much as possible. | ||
A well-crafted Git commit message is the best way to communicate _context_ about a change to the maintainers. The code will tell what changed, but only the commit message can properly tell why. Re-establishing the context of a piece of code is wasteful. We can't avoid it completely, so our efforts should go to reducing it as much as possible. | ||
|
||
Nord adheres to the [Arctic Ice Studio Git Style Guide][gh-styleguide-git]. | ||
|
||
|
@@ -156,7 +156,7 @@ When [reporting a bug](#bug-reports), sometimes even when [suggesting enhancemen | |
- …Complete – Provide all parts needed to reproduce the behavior | ||
- …Verifiable – Test the code you're about to provide to make sure it reproduces the behavior | ||
|
||
A MCVE is a common practice like on [Stack Overflow][stackoverflow-mcve] and sometimes it is also called [SSCCE][sscce], a *Short, Self Contained, Correct (Compilable), Example*. | ||
A MCVE is a common practice like on [Stack Overflow][stackoverflow-mcve] and sometimes it is also called [SSCCE][sscce], a _Short, Self Contained, Correct (Compilable), Example_. | ||
|
||
The recommended way for GitHub based projects is to create it as [Gist][gh-gist] or new repository, but of course you can [attach it to issues and pull requests as files][ghh-attach-file], use any free code paste- or file hosting service or paste the code in [Markdown code blocks][ghh-markdown-code-blocks] into the issue. | ||
|
||
|
@@ -177,7 +177,7 @@ Make sure all resources and code necessary to reproduce the behavior is included | |
|
||
### Verifiable | ||
|
||
To entirely understand your enhancement or bug report, developers will need to verify that it *exists*: | ||
To entirely understand your enhancement or bug report, developers will need to verify that it _exists_: | ||
|
||
- **Follow the contribution guidelines regarding the description and details**. Without information developers won't be able to understand and reproduce the behavior. | ||
- **Eliminate any issues that aren't relevant**. Ensure that there are no compile-time errors. | ||
|
Oops, something went wrong.