0.12.0

0.12.0

⇅ [Show all commits][243]

Improvements

Update to tmpl template repository version 0.11.0 — #86 ⇄ #87 (⊶ cacc9fa)

→ Updated to [tmpl version 0.11.0][244], including the versions in between starting from [0.10.0][245]:

1. [Optimized GitHub action workflow scope][246].
2. [Updated Node.js packages & GitHub actions][247] [^1] [^2].
3. [Opts-in the Dependabot version update configuration][248].
4. [Migrated to Markdown style guide version 0.4.0][249].

This also includes changes required for any linter matches.

svengreb GitHub account and @svengreb npm package scope migration — #88 ⇄ #89 (⊶ 61b554e)

→ With [the retirement of the Arctic Ice Studio personal & Nord project brand][250] this project also moved to the real-in-person identity “Sven Greb“ both in the context of the repository to [the svengreb GitHub account][251] and the @svengreb npm package scope.
During this migration the current npm packages [@arcticicestudio/eslint-config-base][253], [@arcticicestudio/eslint-config][253] and [@arcticicestudio/eslint-config-typescript][254] have been deprecated in favor of the new and upcoming [@svengreb/eslint-config-base][255], [@svengreb/eslint-config][256] and [@svengreb/eslint-config-typescript][257] packages that will be published afterwards.

Also [the visual representation of this style guide][258] through the way too outdated and deprecated [GitBook][259] major version 2 has been unpublished and removed. The documentations and references have been updated to use the GitHub repository with the Markdown rendering instead for now until a custom website has been implemented using a modern TechStack like [Next.js][260].

Migrate to @svengreb/remark-preset-lint npm package — #90 ⇄ #91 (⊶ 5353832)

→ Before the used [@arcticicestudio/remark-preset-lint package][261] has been deprecated during [the svengreb GitHub account and @svengreb npm package scope migration][262] and replaced by the [new @svengreb/remark-preset-lint package][263].

Migrate to ESLint major version 8 — #92 ⇄ #93 (⊶ 19588e5)

0.11.0

Changelog for the official Arctic Ice Studio JavaScript code style.

0.11.0

⇅ Show all commits

Improvements

Allow void operator as a statement for React Hooks — #55 ⇄ #56 (⊶ af9c38b)

↠ To run async code in a React useEffect Hook the official React Hook FAQ section about how to fetch data recommends and shows in a demo how to define a scoped fat arrow function and run it immediately. Unfortunately this collided with the @typescript/no-floating-promises rule because the returned Promise of the called function must not be handled anymore.

useEffect(() => {
  const init = async () => {
    try {
      const data = await fetchData();
      setInitialized(isInit);
      if (data) initStores(data);
    } catch (err) {
      handleError(err);
    }
  };
  // This will trigger the "@typescript/no-floating-promises" rule because the returned "Promise" is not handled.
  init();
}, [fetchData, handleError, initStores, setInitialized]);

Explicitly disabling the rule for these specific code lines would have been an option, but it is recommended to use the void operator instead.

// ...
// This will trigger the "no-void" rule because the "void" operator is currently not allowed as a statement.
void init();
// ...

However, the no-void rule did not allow the void operator to be used as statement which resulted in this rule to also throw an error.
To resolve both problems, the allowAsStatement option of the no-void rule has been enabled.

Also see typescript-eslint/typescript-eslint#1184 where this solution is also recommended by one of the @typescript-eslint package maintainers.

The full changelog is available in the repository

Copyright © 2016-present Sven Greb

0.10.0

Changelog for the official Arctic Ice Studio JavaScript code style.

⇅ [Show all commits][gh-compare-tag-v0.9.0_v0.10.0]

Improvements

@arcticicestudio/remark-preset-lint migration — #47 ⇄ #48 (⊶ 90953d7)

↠ The remark-preset-lint-arcticicestudio package has been deprecated [during the migration into a monorepo][gh#10] and replaced by the new [@arcticicestudio/remark-preset-lint package][gh-tree-pkgs-@ais-remarl-preset-lint]. This package also [introduced support for remark 13.0.0][gh#28] which comes with some new features and great improvements.
To migrate to the new package the remark-preset-lint-arcticicestudio preset has been replaced by the new @arcticicestudio/remark-preset-lint preset in the .remarkrc.js file.

Bug Fixes

Invalid usage of prettier/@typescript-eslint configuration — #49 ⇄ #52 (⊶ c1aca60)

↠ As of [eslint-config-prettier][gh-prettier/eslint-config-prettier] version 8.0.0 all configurations have been merged into the prettier configuration that now includes not just ESLint core rules, but also rules from all plugins.
In #32 the eslint-config-prettier version was bumped from version [v6.0.0 to v8.1.0][gh-prettier/eslint-config-prettier-comp-v6.0.0_v8.1.0], but the @arcticicestudio/eslint-config-typescript package still explicitly extends the prettier/@typescript-eslint configuration which results in an error when consuming the package.

To fix this problem, the prettier/@typescript-eslint has been removed entirely from the extend field, leaving only the all-in-one prettier configuration.

Loop on TypeScript configuration override — #50 ⇄ #53 (⊶ ddc16cc)

↠ In #32 the @arcticicestudio/eslint-config-typescript package migrated to the latest plugin versions and added [the override field][gh-blob-pkgs-@ais-ts-index-ab59f71f#l31-36] to its index to simplify the usage for consumers by removing the need to explicitly define it per project. Unfortunately this resulted in a crash loop when doing so and also blocked users from overriding single rules based on the project needs.

To fix this problem, the override field has been removed again, leaving it up to the user to define and customize the ESLint configuration for TypeScript to fit the project needs.

Invalid usage of prettier/@typescript-eslint configuration — #51 ⇄ #54 (⊶ aba4587)

↠ TypeScript uses [triple-slash directives][typescript-docs-triple_slash_directives] (single-line comments containing a single XML tag) to define compiler directives. The @arcticicestudio/eslint-config-base configures the ESLint core rule [spaced-comment][eslint-rule-spaced-comment] and already defines exceptions and comment markers for special use cases, but did not support triple-slash directives. When running eslint --fix these comments in *.d.ts files were malformed (/// → // /) which resulted in invalid TypeScript syntax.

To support triple-slash directives, the / marker has been added to the line field.

The full changelog is [available in the repository](https://github.com/svengreb/styleguide-javascript/blob/main/changelog.md)

Copyright © 2016-present Sven Greb

0.9.0

Changelog for the official Arctic Ice Studio JavaScript code style.

⇅ [Show all commits][gh-compare-tag-v0.8.0_v0.9.0]

Features

Update ESLint and plugins — #31 ⇄ #32 (⊶ 486b2d1)

↠ ESLint and most of the used plugins released new major versions so trying to use later versions of these plugins as well as ESLint itself caused errors when using npm v7 because [peer dependencies are installed automatically][gh-blog-npm_v7#break_change] now, which is a fantastic change, but also breaks and blocks the usage of the configuration packages due to outdated peerDependencies like eslint@^6.

Core

The latest version 7 comes with great features and improvements.
See the [official v7 migration guide][esl-docs-guides-mig_v7] for all details.

• Updated ESLint package version — updated from [v6.2.0 to v7.23.0][gh-eslint/eslint-comp-v6.2.0_v7.23.0].
• Allowed to define additional file extensions in configuration packages — [files matched by overrides[].files are now linted by default][esl-docs-guides-mig_v7#override_file_match] which allows to add extensions like *.ts and *.tsx to the @arcticicestudio/eslint-config-typescript without the need to specify this override over and over again in each project.
• Removed deprecated rules — [some rules have been deprecated][esl-docs-guides-mig_v7#depr_rules] and have been removed in favor of the support for eslint-plugin-node like documented in #30.
  • [callback-return][esl-docs-rule-callback-return] → [node/callback-return][gh-mysticatea/eslint-plugin-node-blob-docs-rule-callback-return]
  • [global-require][esl-docs-rule-global-require] → [node/global-require][gh-mysticatea/eslint-plugin-node-blob-docs-rule-global-require]
  • [handle-callback-err][esl-docs-rule-handle-callback-err] → [node/handle-callback-err][gh-mysticatea/eslint-plugin-node-blob-docs-rule-handle-callback-err]
  • [no-mixed-requires][esl-docs-rule-no-mixed-requires] → [node/no-mixed-requires][gh-mysticatea/eslint-plugin-node-blob-docs-rule-no-mixed-requires]
  • [no-new-require][esl-docs-rule-no-new-require] → [node/no-new-require][gh-mysticatea/eslint-plugin-node-blob-docs-rule-no-new-require]
  • [no-path-concat][esl-docs-rule-no-path-concat] → [node/no-path-concat][gh-mysticatea/eslint-plugin-node-blob-docs-rule-no-path-concat]
  • [no-process-env][esl-docs-rule-no-process-env] → [node/no-process-env][gh-mysticatea/eslint-plugin-node-blob-docs-rule-no-process-env]
  • [no-process-exit][esl-docs-rule-no-process-exit] → [node/no-process-exit][gh-mysticatea/eslint-plugin-node-blob-docs-rule-no-process-exit]
  • [no-restricted-modules][esl-docs-rule-no-restricted-modules] → [node/no-restricted-modules][gh-mysticatea/eslint-plugin-node-blob-docs-rule-no-restricted-modules]
  • [no-sync][esl-docs-rule-no-sync] → [node/no-sync][gh-mysticatea/eslint-plugin-node-blob-docs-rule-no-sync]
• Adapted new recommended rules — some rules have been [added and enabled on the eslint:recommended rule set][esl-docs-guides-mig_v7#recomm_rules] and have ben added to @arcticicestudio/eslint-config-base with error level:
  • [no-dupe-else-if][esl-docs-rule-no-dupe-else-if]
  • [no-import-assign][esl-docs-rule-no-import-assign]
  • [no-setter-return][esl-docs-rule-no-setter-return]

Plugins & Dependencies

@arcticicestudio/eslint-config

• [eslint-config-prettier][gh-prettier/eslint-config-prettier] — Bumped version from [v6.0.0 to v8.1.0][gh-prettier/eslint-config-prettier-comp-v6.0.0_v8.1.0]. As of [version 8.0.0 all rule sets have been merged into the main prettier set][gh-prettier/eslint-config-prettier-blob-chl#v8.0.0]. Therefore the additional prettier/react set has been removed from the extends array of the Prettier specific rules.
• [eslint-find-rules][gh-sarbbottam/eslint-find-rules] — Bumped version from [v3.4.0 to v3.6.1][gh-sarbbottam/eslint-find-rules-comp-v3.4.0_v3.6.1].
• [eslint-plugin-import][gh-benmosher/eslint-plugin-import] — Bumped minimum version from [v2.18.2 to v2.22.1][gh-benmosher/eslint-plugin-import-comp-v2.18.2_v2.22.1].
• [eslint-plugin-jsx-a11y][gh-jsx-eslint/eslint-plugin-jsx-a11y] — Bumped minimum version from [v6.2.3 to v6.4.1][gh-jsx-eslint/eslint-plugin-jsx-a11y-comp-v6.2.3_v6.4.1].
• [eslint-plugin-prettier][gh-prettier/eslint-plugin-prettier] — Bumped minimum version from [v3.1.0 to v3.3.1][gh-prettier/eslint-plugin-prettier-comp-v3.1.0_v3.3.1].
• [eslint-plugin-react][gh-yannickcr/eslint-plugin-react] — Bumped minimum version from [v7.14.3 to v7.23.1][gh-yannickcr/eslint-plugin-react-comp-v7.14.3_v7.23.1]. This includes new rules and improvements to existing ones:
  • Added new [react/jsx-no-useless-fragment][gh-yannickcr/eslint-plugin-react-blob-docs-rule-jsx-no-useless-fragment] rule with error level (introduced in [v7.15.0][gh-yannickcr/eslint-plugin-react-blob-chl#v7.15.0]) that disallows unnecessary fragments.
  • Added the new static-variables option to the [react/sort-comp][gh-yannickcr/eslint-plugin-react-blob-rules-sort-comp] rule (introduced in [v7.15.0][gh-yannickcr/eslint-plugin-react-blob-chl#v7.15.0]).
  • Added new [react/jsx-newline][gh-yannickcr/eslint-plugin-react-blob-docs-rule-jsx-newline] rule (introduced in [v7.22.0][gh-yannickcr/eslint-plugin-react-blob-chl#v7.22.0]) and disable by default.
  • Added new [react/jsx-no-constructed-context-values][gh-yannickcr/eslint-plugin-react-blob-docs-rule-jsx-no-constructed-context-values] rule (introduced in [v7.22.0][gh-yannickcr/eslint-plugin-react-blob-chl#v7.22.0]) and enabled it by default to prevent react contexts from taking non-stable values.

    React Context, and all its child nodes and Consumers are rerendered whenever the value prop changes. Because each Javascript object carries its own identity, things like object expressions ({foo: "bar"}) or function expressions get a new identity on every run through the component. This makes the context think it has gotten a new object and can cause needless r...

0.8.0

Features

Packages

@arcticicestudio/eslint-config

React Hooks support and entry point — #17 ⇄ #18 (⊶ 833cc51)
↠ All React based Arctic Ice Studio projects using at least React version [16.8][react-b-rln-16.8.0] that introduced the awesome [Hooks][react-d-hooks]. Since this comes with a [entire new API][react-d-hooks-api] that follows new design/usage pattern, the React team created an official [„Hooks“ ESLint plugin][gh-t-esl-p-react-hooks] to help to adhere to the [„Rules of Hooks“][react-d-hooks-rules].

Since the @arcticicestudio/eslint-config package already includes support for React and „JSX A11Y“, support for Hooks has also been added through a new shareable configuration entry point that

• enables the react-hooks plugin.
• configures both currently available rules react-hooks/rules-of-hooks and react-hooks/exhaustive-deps rule to error level.

Because Hooks make more use of arrow functions the [react/jsx-no-bind][gh-esl-p-react-jsx_bind] has been adjusted to prevent compatibility problems by allowing setting the ignoreDOMComponents and allowArrowFunctions options to true.
The react/display-name rule has also been disabled in order to prevent problems due to missing display names for functional components that make use of Hooks instead of being created through a class component.

The new entry point is available as @arcticicestudio/eslint-config/react-hooks and can be composed with all other [available entry points][gh-b-pkg-esl-readme#entry_points] to inherit their rules.

This feature adds the eslint-plugin-react-hooks package as new peer dependency for @arcticicestudio/eslint-config.

ESLint TypeScript Configuration Package — #19 ⇄ #20 (⊶ 484c981)
↠ To support projects build with [TypeScript][], a new @arcticicestudio/eslint-config-typescript package has been implemented using the awesome [@typescript-eslint][gh-tsesl] project. It mainly extends @typescript-eslint/eslint-plugin's [already provided and recommended configurations][gh-tsesl-t-configs] in order to adapt best practices:

1. plugin:@typescript-eslint/eslint-recommended
2. plugin:@typescript-eslint/recommended
3. plugin:@typescript-eslint/recommended-requiring-type-checking

The [@typescript-eslint/parser][gh-tsesl-parser] is set as ESLint parser. As of [@typescript-eslint/parser version 2.0.0][gh-tsesl-rl-2.0.0] (also see [typescript-eslint/typescript-eslint#890][gh-tsesl#890]), the parser will panic when parsing files that are not included within the provided tsconfig(s).
The documentation of the new package contains instructions and a quick setup and usage guide to inform about the [required tsconfig configurations][gh-tsesl-parser#config] and the corresponding eslintrc changes.

Next to the support for TypeScript, the package also modifies some React and import related rules in order to prevent conflicts, like the adaption of the .ts and .tsx extensions for all JS and JSX files as well as removing .jsx to force the usage of .tsx. There are other rules that have been disabled like the check for valid React prop-types since these and not necessary anymore when working with TypeScript.

The new package provides two entry points, available as @arcticicestudio/eslint-config-typescript (main) and @arcticicestudio/eslint-config-typescript/prettier that can both be composed with all other [available entry points][gh-b-pkg-esl-readme#entry_points] to inherit their rules.

This package mainly depends on the @typescript-eslint/eslint-plugin@^2.0.0 and @typescript-eslint/parser@^2.0.0 packages as peer dependencies.

From CircleCI to GitHub Actions — #21 ⇄ #22 (⊶ c7d663e)
↠ The project migrated from [CircleCI][cci] as CI/CD service to the awesome new [GitHub Actions][gh-feat-actions] that is smoothly integrated into the GitHub platform and page for a „single-source-of-truth“ developer experience: OPS configurations as code right next to the source code in the repository.

Previous Project State

The previous project setup used [CircleCI][cci] with [API version 2.x][cci-d] as CI/CD service. This worked great, but also comes with the disadvantage of being decoupled from the repository.

The GitHub Actions CI/CD UI

During GitHub Universe 2018, the awesome new [GitHub Actions][gh-feat-actions] feature was [introduced and launched as closed beta][gh-blog-actions]. Luckily Arctic Ice Studio was given access in order to test all the great possibilities. During the [GitHub Actions stream „Now with built-in CI/CD!“ (live from GitHub HQ)][yt-gh-stream-actions_cicd] the Actions update was announced and previewed showing the expansion to use GitHub Actions as [CI/CD service described as „fast CI/CD for any OS, any language, and any cloud“][gh-blog-actions-cicd].

Live logs showing real-time feedback

See the [official GitHub Actions documentation][gh-help-actions] for details about setups, features, the configuration API and many more!

Project Integration

The switch from CircleCI to GitHub Actions brought many advantages like a „close-to-the-source“ development pipeline. Having the code and automated pipelines/workflows in one place is worth a lot. This also comes along with the perfect and smooth integrations into the GitHub platform and page itself like status reports on PRs and many more possibilities like the [customization and triggering of workflows through webhooks][gh-help-actions-events] for almost every event that can occur in a repository/issue/PR etc.

To integrate GitHub Actions the previous [CircleCI build configuration][gh-b-ac611f7e-circleci] has been adapted and adjusted. The official [starter-workflows][gh-starter-workflows] were used as inspiration as well as showcase projects like [Yarn Berry (Yarn v2)][gh-yarn-berry-t-gh-wrkf] also presented during the announcement livestream.

Next to the starter-workflows repository the [official GitHub Actions documentation][gh-help-actions] was the main source of information to set up the project workflows.

GitHub Actions starter workflows based on the epository languages

Since GitHub Actions are still in closed/limited public beta, there is no support for SVG badges through [shields.io][]. Anyway, there are (currently undocumented) official badges provided by the GitHub API that are used until Actions goes GA and [shields.io][] implements support for it: https://github.com/{owner}/{repo}/workflows/{workflow_name}/badge.svg

The full changelog is available in the repository

0.7.0

Epics

Monorepo with ESLint packages — #8 ⇄ #16 (⊶ ac611f7)
↠ Resolved the epic by converting the repository into a [monorepo][trbdev-monorepo] and migrating the [@arcticicestudio/eslint-config][gh-t-pkg-esl] (previously eslint-config-arcticicestudio) + [@arcticicestudio/eslint-config-base][gh-t-pkg-esl-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][gh-t-pkg-esl] (previously eslint-config-arcticicestudio) and [@arcticicestudio/eslint-config-base][gh-t-pkg-esl-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][trbdev-monorepo] 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][trbdev-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][gh-t-pkg-esl] (previously eslint-config-arcticicestudio) and [@arcticicestudio/eslint-config-base][gh-t-pkg-esl-base] (previously eslint-config-arcticicestudio-base), have been migrated into this repository by adapting to [Yarn workspaces][yarn-d-ws] 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][npm-d-scope] 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][esl-d-dev-share_conf#scope].
The previously released public versions [have been deprecated using the npm deprecate command][npm-cli-dep] 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][gh-blog-multi-issue-templ] while the [initial template file][gh-blog-intro-issue-templ] is used as a fallback/generic template to link to the specific ones.

Read the [GitHub Help article][gh-help-issue-templ] for more details about issue and pull request templates. Also check out how to manually create [issue templates][gh-help-pr-templ], a [pull request template][gh-help-issue-templ-repo]. and the guide on [how to create the (deprecated) fallback/generic issue template][gh-help-issue-templ-depr].

Improvements

General repository and package documentations and metadata — #14 (⊶ be122b1)
↠ The previous project repository documentations were not designed for a [monorepo][trbdev-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][gh-remark-lint], a linter built on [remark][], the powerful Markdown processor powered by plugins such as remark-lint.
It is used through [remark-cli][gh-remark-cli] with [remark-preset-lint-arcticicestudio][gh-remark-preset-lint-arcticicestudio], the custom preset that implements the [Arctic ice Studio Markdown Style Guide][styleguide-markdown].

To lint all Markdown sources within the project the lint:md NPM script has been added that will ...

0.1.0

The Arctic Ice Studio JavaScript Code Style based on the Airbnb JavaScript Style Guide.

---

Detailed information can be found in the project documentation.

Features

Style Guide

❯ Added the initial style guide with chapters to learn about the comprehensive base rules. (#1 in PR #2, dee0441)

❯ Added the initial style guide for React specific rules like e.g. Higher-Order Components, the component methods & properties ordering and props. (#3 in PR #4, cee7114)

The full changelog is available in the repository

Copyright © 2016-present Sven Greb