arcticicestudio / arctic Goto Github PK

Integrate Husky, the tool that make Git hooks easy and can prevent bad Git commits, pushes and more 🐶 woof!

Configuration

The configuration file .huskyrc.js will be placed in the project root and includes the command to run for any supported Git hook. It will at least contain configs for the following hooks:

• pre-commit - Run lint-staged (#33) before each commit to ensure all staged files are compliant to all style guides.

Tasks

• Install husky package.
• Implement .huskyrc.js configuration file.

Integrate ESLint, the pluggable and de-facto standard linting utility for JavaScript.

Configuration Preset

The configuration presets that will be used are @arcticicestudio/eslint-config that implements the Arctic Ice Studio JavaScript Style. It comes with the following peer dependencies:

• eslint
• babel-eslint

It it built on top of @arcticicestudio/eslint-config-base that includes various rules of the following plugins and rule presets that are therefore also required peer dependencies:

• @typescript-eslint/eslint-plugin
• @typescript-eslint/parser
• eslint-config-prettier
• eslint-plugin-babel
• eslint-plugin-import
• eslint-plugin-jsx-a11y
• eslint-plugin-prettier
• eslint-plugin-react-hooks
• eslint-plugin-react

Since arctic will be built with TypeScript, the @arcticicestudio/eslint-config-typescript preset will be extended to add support for TypeScript source file linting and compatibility with Prettier through the @arcticicestudio/eslint-config-typescript/prettier extension entry point. This preset requires the following peer dependencies:

• @typescript-eslint/eslint-plugin
• @typescript-eslint/parser
• typescript

Since the custom presets are still in major version 0 note that the version range should be >=0.x.x <1.0.0 to avoid the “SemVer Major Zero Caveat”. When defining package versions with the the carat ^ or tilde ~ range selector it won't affect packages with a major version of 0. yarn will resolve these packages to their exact version until the major version is greater or equal to 1.
To avoid this caveat the more detailed version range >=0.x.x <1.0.0 should be used to resolve all versions greater or equal to 0.x.x but less than 1.0.0. This will always use the latest 0.x.x version and removes the need to increment the version manually on each new release.

To allow to lint TypeScript code the @typescript-eslint/parser parser will be used and specified as parser next to the main Babel parser. Also to make use of the latest experimental Babel features and proposals, eslint-plugin-babel will be added with the following rule configurations:

• babel/camelcase with level error - doesn't complain about optional chaining (let foo = bar?.a_b;). Note that the core rule camelcase must be disabled!
• babel/no-unused-expressions with level error - doesn't fail when using do expressions or optional chaining (a?.b()). Note that the core rule no-unused-expressions must be disabled!

See the documentation of provided rulesand required configurations to use them.

The .eslintrc.js configuration file will be placed in the project root next to the .eslintignore file to define ignore pattern.

Webpack Import Resolving Strategy

To prepare for a better developer experience with Webpack (that will be used later on through Gatsby) the resolvers of the eslint-plugin-import will be configured for the src and src/components paths.

Package Script

To allow to run the JavaScript linting separately a lint:js npm script/task will be added to be included in the main lint script flow. To use the great auto-fixing feature another format:js script/task will be added.

Tasks

• Install required packages to as development dependencies:
  • @arcticicestudio/eslint-config-typescript
  • @arcticicestudio/eslint-config
  • eslint-config-prettier
  • eslint-plugin-babel
  • eslint-plugin-import
  • eslint-plugin-jsx-a11y
  • eslint-plugin-prettier
  • eslint-plugin-react-hooks
  • eslint-plugin-react
  • eslint
  • typescript
• Implement .eslintrc.js configuration file.
  • Extend installed presets.
  • Prepare Webpack compatibility with resolvers.
  • Integrate eslint-plugin-babel
    • Enable babel/no-unused-expressions and babel/camelcase rules including the deactivation of their associated core rules.
    • Add babel to the array of enabled plugins.
• Implement .eslintignore ignore pattern file.
• Implement npm format:fix-js, format:fix-ts, lint:js and lint:ts scripts.
• Lint current code base for the first time and fix possible JavaScript style guide violations.

This epic documents the design concept for the brand design & styling of arctic.

🚧 This is a living document which means it is work in progress, not completed yet and will be extended!

Associated epic: #12

To achieve a consistent and uniform style and layout, the basic HTML elements, like e.g. a <h1> or <ul> should be used through a React component. These components render to the base HTML element they represent, but will apply styles, behavior and layout properties to ensure they match the project's design guidelines instead of using default browser configurations that might be even differ for each user agent.
This allows to use base HTML elements with all the advantages of React and JS without worrying about different render output.

This collection issue tracks the implementations of all the different individual React components. They are all based on the awesome MDN HTML elements reference documentation and will use the same categorization.

Inline Text Semantics

A

Implemented by: -

Represents the <a> HTML element (or anchor element). This is a special dynamic and failsafe component since it'll internally use Gatsby Link to route within the site (internal links) while also being able to link to external data.
This will be handled through a utility function to conditionally render based on the passed target URL (internal & external).

This epic documents the design concept for the React function and class components of arctic. The architecture and project structure is documented in the “Component & Project Structure” design concept.

🚧 This is a living document which means it is work in progress, not completed yet and will be extended!

GitHub provides a feature to define multiple issue templates.

The initial template file that has been used when the feature was introduced can now be used as a fallback/generic template.

The UI helps users to open a new issue in projects by prompting them to choose from multiple issue types.

See the GitHub Help for more details about issue and pull request templates. Also check out how to manually create issue templates and a pull request template. There's also a guide on how to create the (deprecated) fallback/generic issue template.

Add the LICENSE.md file for the MIT license.

This epic documents the icon design concept of arctic. It defines the process steps to decide about all iconography aspects like the base sizes and usage within components/themes.

🚧 This is a living document which means it is work in progress, not completed yet and will be extended!

This epic documents the design concept of the static site generator that'll be used to build arctic’s and serves as a plan for the initial launch. It defines the process steps to decide about aspects like the Gatsby core configuration, Gatsby API implementations, required Gatsby plugins, custom configurations for Babel and Webpack and many more.

🚧 This is a living document which means it is work in progress, not completed yet and will be extended!

What is Gatsby?

Gatsby is a blazing fast modern site generator to build secure, modern and blazing fast websites and apps with React. It is fully compliant to JAMstack which is the web development architecture used to built arctic as documented in #3.

• Gatsby is one of the most popular and state-of-the-art projects of its kind, comes with many unique features builtin into the core while being fully extensible through a advanced plugin API with an large ecosystem.
• Gatsby generates PWAs (Progressive Web App) with code and data splitting out-of-the-box™ to only load the critical HTML, CSS, data, and JavaScript so the website loads as fast as possible and prefetches resources for other pages once loaded while clicking around the site to make it feel incredibly fast.
• Gatsby scales to the entire internet by building sites as “static” files which can be deployed easily on dozens of services and fits perfect when used in combination with a continuous deployment concept like e.g. like Netlify (see #9).
• Gatsby provides data through a GraphQL API that can be injected into every component and page while the data can be pulled from almost every source: headless CMSs, SaaS services, APIs, databases, the file system…

Gatsby is much more than just a static “site” generator powered by React as explained by the founder and core team members:

It produces static HTML and then rehydrates into a React app.
Think of it as an opinionated CRA with built-in SSR and nice integrations with CMS.
Gatsby is also there to build apps. — Kyle Mathhews, Founder of Gatsby

Gatsby can handle apps with:

• User authentication? ✅
• Dynamic data? ✅
• Asynchronous requests? ✅
• Ecommerce? ✅
• Full-blown SaaS? ✅

You can do SO MUCH MORE than static sites with Gatsby. — Jason Lengstorf , Gatsby Core Team Developer

There are countless more features, but it is out of scope for this document to introduce these here. Instead, make sure to check their official project website with the extensive, well-written docs and really intense and beginner-friendly tutorials. It also includes a large overview and comparison of all features, a plugin library and inspiring showcases.
In their blog they publish a lot of great guides, tips & tricks and articles like how Gatsy got so popular that they founded Gatsby Inc. and blog posts about the companies feature plans and values.

Implementation Plan

To build arctic with Gatsby there are several process steps that must be planned and implemented. This section splits it up into categories and theirs tasks that will be documented and tracked within this epic.

Gatsby Themes

On July 3rd 2019, the long-awaited Gatsby Themes API was announced.
This allows to extract logic and components into own packages that can be composed together for reuse in other Gatsby projects or as template/starter for new projects.

arctic will make use of this awesome feature by implementing splitting up into multiple scoped (@arcticicestudio) packages for a simply modularized code base:

1. @arcticicestudio/gatsby-theme-arctic-core — A Gatsby Theme that provides basic and essential plugins and configurations that can simply be used in other projects or serve as base theme. It'll try to be as generic as possible while still being dynamic configurable.
2. @arcticicestudio/gatsby-theme-arctic-core — The main Gatsby Theme that'll be more opinionated when it comes to CSS-in-JS libraries and usage of other larger projects/plugins that are not only targeted to basic/essential configurations. It will be the main source for core components and layouts that can be used to extend another Gatsby Theme on.
3. www — The package of the website itself. It will use and compose both Gatsby Theme packages and adds additional Gatsby plugins and configurations specific to the site as well as plugins that can only be applied in this package due to their required loading order (e.g. gatsby-plugin-offline).

Since arctic’s repository structure is a monorepo, the modular architecture comes with even more improvements like hoisted dependencies and a way smoother developer experience due to direct loading of local packages.

Core Configuration

The core configuration of Gatsby is the gatsby-config.js file that will be placed in the root directories of the theme and website packages. It defines project-wide site metadata that can be used through the GraphQL API and configures all plugins that will be used.

All implementation details and requirements are documented and tracked in the corresponding issues:

• #35 (⊶ -) „Gatsby initial configuration“ — in progress ∞

API Implementations

Gatsby can be customized and extended to the core by providing…

• …the Node API that gives plugins and site builders many APIs for controlling the build process. It can be implemented in the gatsby-config.js file placed in the project root.
• …the SSR API to hook into the server-side rendering process. It can be implemented in the gatsby-ssr.js file placed in the project root.
• … the Browser API to hook into the APIs used for browser related functionality. It can be implemented in the gatsby-browser.js file placed in the project root.

All APIs come with a collection of functions called “Actions” that can be used to manipulate the build.

For more details make sure to read the API specification and philosophy and references for the GraphQL API.

All implementation details and requirements are documented and tracked in the corresponding issues:

• #35 (⊶ -) „Gatsby initial configuration“ — in progress ∞

Gatsby Plugins

Gatsby is designed to be easily extensible while being functional out-of-the-box™. This is possible by using the powerful plugin API to simply create own plugins or browse the plugin library since there is already a large ecosystem and a plugin for almost everything.

arctic will make use of various plugins to implement features and simplify the code base for a better developer experience.

All implementation details and requirements are documented and tracked in the corresponding issues:

• #35 (⊶ -) „Gatsby initial configuration“ — in progress ∞

Babel Configuration Modification

Gatsby comes with an already optimized Babel configuration to create SSR “static” websites and apps, but there are also use cases that require to modify and extend this configuration to e.g. add a new Babel plugin for the latest syntax feature/proposal support.
Of course Gatsby provides a way through the Node API by implementing the onCreateBabelConfig function.

All implementation details and requirements are documented and tracked in the corresponding issues:

• #35 (⊶ -) „Gatsby initial configuration“ — in progress ∞

Webpack Configuration Modification

This is almost the same like the section above about how to modify and extend the Babel configuration but now for Webpack instead of Babel. This can be necessary to e.g. add a builtin or third-party plugin or to add resolve aliases. For sure Gatsby supports this too by providing the onCreateWebpackConfig function through the Node API.

All implementation details and requirements are documented and tracked in the corresponding issues:

• #35 (⊶ -) „Gatsby initial configuration“ — in progress ∞

Add the .yarnrc and .npmrc configuration files to enforce project-wide standards for all core team members and contributors. This includes the usage of the Yarn and npm exact version resolution as well as disabling the creation of the npm package-lock.json file in order to prevent conflicts with the yarn.lock file.

This epic documents the design concept for the [continuous integration][wiki-ci] & testing of arctic to ensure a great project quality.

🚧 This is a living document which means it is work in progress, not completed yet and will be extended!

This epic documents the design concept of arctic’s web development architecture and serves as a plan for the initial launch.
It defines the process steps of the three key criteria.

🚧 This is a living document which means it is work in progress, not completed yet and will be extended!

What is the JAMstack?

JAMstack: noun \’jam-stak’
Modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.

It is not about specific technologies, but a new way of building websites and apps that delivers better performance, higher security, lower cost of scaling, and a better developer experience.

A project is built with the JAMstack if it meets the three key criteria JavaScript, APIs and Markup:

Any dynamic programming during the request/response cycle is handled by JavaScript, running entirely on the client. This could be any frontend framework, library, or even vanilla JavaScript.

All server-side processes or database actions are abstracted into reusable APIs, accessed over HTTPS with JavaScript. These can be custom-built or leverage third-party services.

Templated markup should be prebuilt at deploy time, usually using a site generator for content sites, or a build tool for web apps.

For detailed information check out the official website that provides information about how projects can adapt to it, best practices, examples, resources and a great community.

JavaScript

Implementation issues: #4

Any dynamic programming during the request/response cycle is handled by JavaScript, running entirely on the client. This could be any frontend framework, library, or even vanilla JavaScript.

We 💙 React!

All web related projects developed by Arctic Ice Studio are built with React and we're not alone. React is not just a trend, it's more like a new standard how the web is built. It revolutionized the way to think about the components a website is made of and how to compose and orchestrate them to form a fluid running unit. It's finally a new way to solve the complicated topic of state handling and the most performant technique to update only necessary parts of the DOM without the large overhead to re-render it completely every time.

React describes itself as…

• Declarative - painless to create interactive UIs and design simple views for each state in applications where React will efficiently update and render just the right components when the data changes. Declarative views makes code more predictable and easier to debug.
• Component-Based - Build encapsulated components that manage their own state, then compose them to make complex UIs and since component logic is written in JavaScript instead of templates, it is easy to pass rich data through the app and keep state out of the DOM.
• Learn Once, Write Anywhere - React doesn’t make assumptions about the rest of the technology stack, so developing new features in React without rewriting existing code can be done easily.

Next to this React can also render on the server using Node and power mobile apps using React Native.

There are so many more arguments and we think all most every developer heard or read about it so this little summary here is only a small introduction.
If you like to get to know more about React, your first touchpoint should be the official website and their extensive and absolute fantastic docs, tutorials and blog. They are maintained and well-written by the React core team itself and the contributors from one of the largest open source community. They are made with a flat learning curve in mind to be very beginner-friendly but at the same time are the main source for every advanced and experienced React developer. They increase the degree of knowledge up to deep-dives into the heart of React and include many great articles about best practices, how to increase the performance and maintainability of apps, the latest features and updates from the React ecosystem, tips & tricks of the core team and many more.

arctic will be built with the currently latest stable version 16.9.0, making use of the awesome Hooks, and will update and adapt to upcoming features like Suspend (aka Async Rendering) when they become stable to always enhance the project and code base.

All implementation details and requirements are documented and tracked in the corresponding issues:

• #35 (⊶ -) „Gatsby initial configuration“ — in progress ∞

APIs

Implementation issues: #4

The plan is to make use of the official GitHub GraphQL API (v4) to get data about projects which can then be used to e.g. show the actual count of stars, the latest release version, interact with issues and pull requests and many more. There are also GitHub Apps that allow to work and interact with the projects.

More APIs might be added later on for many more flexible data fetching using the awesome GraphQL API provided by Gatsby (implemented in #4).

Markup

Implementation issues: #4

This criteria is the actual content of a website.
Gatsby (#4) allows to use Markdown for it. This comes with the nice side effect that the already existing documentations can simply be adapted and reused, but unfortunately it is limited to it's reduced and simplified syntax.

To use the great power of React this project will make use of the MDX specification, a new language and abstract syntax tree definition.

In order to ensure a vibrant ecosystem and community, tooling needs to exist for formatting, linting, and plugins. This tooling requires a foundational specification and abstract syntax tree so that parsing is properly handled before transforming to JSX/Hyperscript/React/etc and potentially leveraging existing plugin ecosystems.

We will use the official implementation, the fully-featured MDX parser, loader and JSX renderer to allow to seamlessly use JSX in Markdown documents by importing components and export metadata or any other ECMAScript compliant data structures like frontmatter.

• 💻 Everything is a component: Use existing components inside your MDX and import other MDX files as plain components.
• 🔧 Customizable: Decide which component is rendered for each Markdown element ({ h1: MyHeading }).
• 📚 Markdown-based: The simplicity and elegance of Markdown remains, you interleave JSX only when you want to.
• 🔥 Blazingly blazing fast: MDX has no runtime, all compilation occurs during the build stage.

More details are provided through the official website that includes docs to get started, usage examples and advanced configuration and customization information.

Add the EditorConfig file to define and maintain consistent coding styles between different editors and IDEs.

This epic documents the icon design concept of arctic Analytics and Statistics evaluation. It defines the process steps to decide about the usage reach and necessity as well as respecting the privacy of users.

🚧 This is a living document which means it is work in progress, not completed yet and will be extended!

Related epics: #6

The Root core container will be the first and one of the important main data provider components of the main Gatsby Theme. It represents the base element and entry point that wraps custom application components and serves as a data provider later on. Some of the tasks in the future will be to

• provide context props and functions for the global styled-components theme through the ThemeProvider component
• inject global styles through styled-components createglobalstyle function including typography (#5) related data like application-wide used fonts
• possibly data stores for state management libraries like MobX

Tasks

• Initially implement the container component Root that renders the passed children within a React.Fragment.
• Initially implement the Landing root/index page rendering the Root component.

Related epics: #4, #6

Initially implement the Gatsby theme and main website package configurations. The gatsby-config.js files of each Gatsby Theme will define project-wide site metadata that can be used through the GraphQL API and configures all plugins that will be used including the Gatsby themes.

Site Metadata

All metadata will be, like defined in #6, placed in the corresponding folders for configurations (src/config) and data (src/data). Initially this will include information stored in the package.json file of the project. There will also be constants for important project root folders to be used in imports later on like route mappings.

Gatsby Plugins

This initial implementations will include the following basic plugins and packages, split up into the corresponding Gatsby theme packages.

1. @arcticicestudio/gatsby-theme-core
   • gatsby-plugin-canonical-urls
   • gatsby-plugin-catch-links
   • gatsby-plugin-no-sourcemaps
   • gatsby-plugin-react-helmet
   • gatsby-plugin-remove-trailing-slashes
   • gatsby-plugin-robots-txt
   • gatsby-plugin-sharp
   • gatsby-plugin-sitemap
   • gatsby-plugin-typescript
   • gatsby-plugin-webpack-size
   • gatsby-source-filesystem
   • gatsby-transformer-hjson
   • gatsby-transformer-json
   • gatsby-transformer-sharp
   • gatsby-transformer-yaml
2. @arcticicestudio/gatsby-theme-arctic
   • gatsby-plugin-svgr
   • gatsby-plugin-styled-components
   • gatsby-image
3. www
   • gatsby-plugin-offline
   • gatsby-plugin-netlify
   • gatsby-plugin-manifest

Package Scripts

To provide a simple development flow, new package scripts will be created to start the Gatsby’s development mode and build a production bundle. This also includes basic scripts like a clean up to remove possible cache problems and previously created bundles and the currently not available „collected“ scripts to run all scripts of the same type/task. The npm-run-all package will be used to simplify the scripts and prevent unnecessary long chained commands and OS related problems.

Gatsby comes with an already optimized Babel configuration to create SSR “static” websites and apps, but there are also use cases that require to modify and extend this configuration to e.g. add a new Babel plugin for the latest syntax feature/proposal support.
Of course Gatsby provides a way through the Node API by implementing the onCreateBabelConfig function.

arctic will make use of the following proposals and plugins:

• “ES Class Fields & Static Properties” through @babel/plugin-proposal-class-properties (NOTE: This plugin will be configured with the enabled loose option!)
• “ECMAScript Proposal: export default from” through @babel/plugin-proposal-export-default-from
• babel-plugin-react-remove-properties to remove props from React elements like data-testid attributes added for simplified querying in automated tests.

The plugins and Babel options will be implemented using Gatsby’s provided actions setBabelPlugin and setBabelOptions.

This is almost the same like the modified Babel configuration documented above, but for the Webpack configuration instead. It will be used to

• configure the plugin webpack-bundle-analyzer to generate a “static” report with a JSON stats file stored in a newly created build directory within the project root.
• configure the plugin git-revision-webpack-plugin
• configure the plugin webpack.DefinePlugin
• configure resolve aliases (see #6 for details about the structure concept)
  • ~assets ➜ src/assets
  • ~atoms ➜ src/atoms
  • ~config ➜ src/config
  • ~containers ➜ src/containers
  • ~data ➜ src/data
  • ~hooks ➜ src/hooks
  • ~hooks ➜ src/layouts
  • ~molecules ➜ src/molecules
  • ~organisms ➜ src/organisms
  • ~pages ➜ src/pages
  • ~stores ➜ src/stores
  • ~styles ➜ src/styles
  • ~templates ➜ src/templates
  • ~utils ➜ src/utils

Gatsby also supports this by providing the onCreateWebpackConfig function through the Node API.

In order to make the Webpack alias imports with TypeScript, the module resolution will be configured to make the alias names and paths available to the compiler.

Since Gatsby v2, React is a peer dependency which allows users to freely choose the version they'd like to use. arctic will initially be build with the currently latest stable version 16.9.0.

Tasks

• Install react and react-dom packages
• Install and configure the main gatsby packages and all basic plugins.
• Create constants and site metadata configurations.
• Implement the new package scripts.
• Install required Babel plugin and proposal packages:
  • @babel/plugin-proposal-class-properties
  • @babel/plugin-proposal-export-default-from
• Configure proposal plugins via the setBabelPlugin API function.
• Configure https://github.com/oliviertassinari/babel-plugin-react-remove-properties for production builds to remove data-testid test attributes.
• Install required Webpack plugin packages:
  • webpack-bundle-analyzer
  • git-revision-webpack-plugin
• Configure resolve aliases for
• Configure git-revision-webpack-plugin to provide the version, commit hash and branch as environment variables through through the webpack.DefinePlugin.
• Configure webpack-bundle-analyzer to generate a “static” report with a JSON stats file stored in a newly created build directory within the project root.

Initialize the package.json file that contains the project's metadata and Yarn workspace definitions.

This epic documents the design concept for the SEO (Search Engine Optimization) & social media representation of arctic.

🚧 This is a living document which means it is work in progress, not completed yet and will be extended!

This epic documents the design concept for the responsive web design pattern of arctic which is the most used, best thought out and Google’s recommended design pattern that provides a great user experience and the best SEO through multi-device & full mobile compatibility.

🚧 This is a living document which means it is work in progress, not completed yet and will be extended!

This epic documents the project concept and serves as a plan for the initial launch. It defines the web design process in several steps this project will go through. It is also the main issue to track all related sub-epics that contain detailed documentations about the concepts described in this issue.

🚧 This is a living document which means it is work in progress, not completed yet and will be extended!

The project should adapt to GitHub's code owners feature. This will allow to define matching pattern for project paths to automatically add all required reviewers of the core team and contributors to new PRs.

See GitHub Help for more details.

Sidebar for code owner PR review requests and review stats

Branch protection configuration to enable required code owner review approvals

PR status checks when required code owner review is pending

Integrate remark-lint which is built on remark, the powerful Markdown processor powered by plugins such as remark-lint.

Ensuring theMarkdown you (and contributors) write is of great quality will provide better rendering in all the different markdown parsers, and makes sure less refactoring is needed afterwards.

remark-lint can be used via remark-cli and a rule preset. This preset will be remark-preset-lint-arcticicestudio, the custom preset that implements the Arctic ice Studio Markdown Style Guide.

Since the custom preset is still in major version 0 note that the version range should be >=0.x.x <1.0.0 to avoid the “SemVer Major Zero Caveat”. When defining package versions with the the carat ^ or tilde ~ range selector it won't affect packages with a major version of 0. yarn will resolve these packages to their exact version until the major version is greater or equal to 1.
To avoid this caveat the more detailed version range >=0.x.x <1.0.0 should be used to resolve all versions greater or equal to 0.x.x but less than 1.0.0. This will always use the latest 0.x.x version and removes the need to increment the version manually on each new release.

Configuration

The .remarkrc.js configuration file will be placed in the project root as well as the .remarkignore file to also define ignore pattern.

Package script/task

To allow to run the Markdown linting separately a lint:md package script/task will be added to be included in the main lint script flow.

Tasks

• Install remark-cli and remark-preset-lint-arcticicestudio packages as development dependency.
• Implement .remarkrc.js configuration file.
• Implement .remarkignore ignore pattern file.
• Implement package lint:md script/task.
• Lint current code base for the first time and fix possible Markdown style guide violations.

Image source: Kent C. Dodds's awesome ["Testing JavaScript"][testingjavascript] workshop
All rights on the image belong to https://testingjavascript.com

This epic documents the design concept of the testing architecture of arctic to ensure the project has a high quality as much as possible. Therefore a setup of stable and proven testing principles, libraries and tools will be used which are tailored for React based projects.

🚧 This is a living document which means it is work in progress, not completed yet and will be extended!

Unfortunately it looks like the Netlify website host isn't hosting this site anymore.

This epic documents the design concept for the continuous deployment & hosting of arctic with Netlify, a fantastic and one of the most popular services providing a single, simplified deployment workflow and a great hosting performance through a ultra-redundant global Application Delivery Network. They invest a lot into the open source community by hosting public projects for free with a lot of features like HTTPS with a free TLS certificate via Let's Encrypt, custom domain, automated preview deployments through integrations with GitHub and many more awesome features.
Listing all of the almost endless features is out-of-scope of this document. The well-written and really extensive documentation contains all information to get started. It also includes a lot of videos in sections to introduce a feature or guide the user through a setup with a tutorial.

🚧 This is a living document which means it is work in progress, not completed yet and will be extended!

This issue documents arctic’s typography design concept and serves as a plan for the initial launch.
It defines the process steps to decide about all typography aspects like the font face, base sizes, usage within components/themes and the modular scale(s).

🚧 This is a living document which means it is work in progress, not completed yet and will be extended!

Associated epic(s): #4

Configure TypeScript, the typed superset of JavaScript that compiles to plain JavaScript.
This is the main language on which arctic will be built.
Like documented in the „Gatsby“ design concept, it will be used in combination with Gatsby later on with the gatsby-plugin-typescript plugin.

Note that TypeScript is only used as linter/validator and not as compiler. The actual compiler is Babel that is configured and used through Gatsby.

Configuration

The root project will provide the main tsconfig for all packages and the website itself.

Package script

To allow to run the TypeScript linting separately a lint:ts package script will be added that'll also be run through the main lint script flow.

Tasks

• Implement the root tsconfig.json file.
• Implement the package lint:ts script.

Depends on #22

GitHub introduced a feature for recommended community standards. arctic tries to adhere to the great Open Source Guides and will adapt to the recommendations to complete the projects community profile.

Code of Conduct

To facilitate a healthy and constructive community behavior, arctic will adhere and enforce a code of conduct.

It will include sections about

• what we believe in and how we act
• unacceptable behavior
• the responsibilities of the maintainer
• the enforcement of the Code of Conduct
• consequences for violations
• the scope of the Code of Conduct

See the GitHub Help for more details about the provided integrations.

Contributing Guidelines

The contribution guidelines help to build a community that encourages people to use, contribute to, and evangelize a project.

It will include sections about

• how to get started
• bug reports
• enhancement suggestions
• pull requests
• style guides
  • JavaScript Style Guide
  • Markdown Style Guide
  • Git Style Guide
• credits

See the GitHub introduction blog post and GitHub Help for more details about the provided integrations.

Add the .gitattributes and .gitignore configuration files to define the pattern.

This epic documents the design concept of the structure for React components, the general layout of the project files and the composition of content like the docs, guides and blog posts.

🚧 This is a living document which means it is work in progress, not completed yet and will be extended!

Integrate lint-staged 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 will be 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 (#32) against *.{js,json,md,mdx,ts,tsx,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 (#30) against *.{js,ts,tsx} to ensure all TypeScript and JavaScript files are compliant to the style guide after being formatted with Prettier.
3. remark --no-stdout - Run remark-lint (#27) 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.

Tasks

• Install lint-staged package.
• Implement lint-staged.config.js configuration file.

Add a Git mailmap file to link to in documentations to 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.

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.

ESLint Compatibility

To be fully compatible with ESLint, eslint-plugin-prettier has already been included in #30 as well as the set of recommended rules via the @arcticicestudio/eslint-config/prettier and @arcticicestudio/eslint-config-typescript/prettier extension entry points.

Package Script

To allow to format all sources a format:pretty package script will be added that'll also run in the main format script flow.

A new lint:pretty script will also allow to check if all supported files are correct formatted. It will be included in the main lint script flow.

Tasks

• Install prettier. Resolved in #30
• Implement prettier.config.js configuration file.
• Implement .prettierignore ignore pattern file.
• Implement format:pretty package script and add to main format script flow.
• Format current code base for the first time and fix possible style guide violations using the configured linters of the project.