refactor: Added format script; Formatted docs

docs/accessibility-statement.md

@@ -32,12 +32,12 @@ Common Gatsby workflows involve third-party products and services, such as sourc
 
 Our current recommendations for accessible CMS platforms are:
 
-- WordPress with the Classic Editor Plugin
-- Drupal
+-   WordPress with the Classic Editor Plugin
+-   Drupal
 
 For managing and deploying Gatsby sites with accessible tools, we recommend:
 
-- Netlify
+-   Netlify
 
 To provide feedback for third-party services, you can contact those vendors directly or [write to us](mailto:marcy@gatsbyjs.com), and we will do our best to pass the information along. We're also interested in hearing about your successes with third-party platforms!
 

docs/blog/2017-02-21-1-0-progress-update-where-came-from-where-going/index.md

@@ -13,24 +13,24 @@ as you develop, ship, and maintain sites.
 
 This framework would have to be:
 
-- **universal**, work for all types of sites from simple brochureware to complex
-  web-apps.
-- **simple**, not requiring any setup to start using and with thoughtful APIs to
-  extend the framework.
-- **fast**, doesn't lose customers to slow page loads. Takes advantage of
-  HTTP/2, browser caching, service workers, inlined critical css, and code
-  splitting so your site always loads incredibly fast—no matter what you build.
-- **JavaScript-driven**, the web is huge and intensely competitive. Sites that
-  win are fast and richly interactive. Your framework must make it trivial to
-  use advanced JavaScript.
-- **team ready**, use industry standard collaboration tools like NPM, Git, and
-  continuous deployment, so your team is always on the same page and shipping
-  new features is easy.
-- **modular**, allows for cleanly separated features so fixing bugs and adding
-  new features is easy and complexity is contained.
-- **internet scale**, launch your site to millions without crashing your site
-  (or your wallet).
-- **secure**, doesn't put your users' data at risk of hacking.
+-   **universal**, work for all types of sites from simple brochureware to complex
+    web-apps.
+-   **simple**, not requiring any setup to start using and with thoughtful APIs to
+    extend the framework.
+-   **fast**, doesn't lose customers to slow page loads. Takes advantage of
+    HTTP/2, browser caching, service workers, inlined critical css, and code
+    splitting so your site always loads incredibly fast—no matter what you build.
+-   **JavaScript-driven**, the web is huge and intensely competitive. Sites that
+    win are fast and richly interactive. Your framework must make it trivial to
+    use advanced JavaScript.
+-   **team ready**, use industry standard collaboration tools like NPM, Git, and
+    continuous deployment, so your team is always on the same page and shipping
+    new features is easy.
+-   **modular**, allows for cleanly separated features so fixing bugs and adding
+    new features is easy and complexity is contained.
+-   **internet scale**, launch your site to millions without crashing your site
+    (or your wallet).
+-   **secure**, doesn't put your users' data at risk of hacking.
 
 I believe that Gatsby fulfills these requirements. After several years of
 working on the project and seeing it used successfully by many people on a wide
@@ -57,9 +57,9 @@ including blogs, marketing sites, documentation sites, and e-commerce.
 It wraps three of the most popular web app tools into a cohesive website
 framework:
 
-- [React](https://facebook.github.io/react/) from Facebook for building UIs
-- [Webpack](https://webpack.js.org/) for bundling JavaScript and CSS
-- [GraphQL](http://graphql.org/) from Facebook for declarative data queries
+-   [React](https://facebook.github.io/react/) from Facebook for building UIs
+-   [Webpack](https://webpack.js.org/) for bundling JavaScript and CSS
+-   [GraphQL](http://graphql.org/) from Facebook for declarative data queries
 
 While designing Gatsby, I wanted a synthesis of two of my favorite developer
 experiences. The simplicity of building sites with markdown and static site
@@ -210,12 +210,12 @@ plugins for internal projects and as open source projects published on NPM.
 
 Plugins can:
 
-- add support for webpack loaders such as Sass, Less
-- add drop-in support for lightweight React-compatible frameworks
-  [Preact](https://preactjs.com/) and [Inferno](https://infernojs.org/)
-- add a sitemap or RSS feed
-- add [Google Analytics](/packages/gatsby-plugin-google-analytics/)
-- ...and many more!
+-   add support for webpack loaders such as Sass, Less
+-   add drop-in support for lightweight React-compatible frameworks
+    [Preact](https://preactjs.com/) and [Inferno](https://infernojs.org/)
+-   add a sitemap or RSS feed
+-   add [Google Analytics](/packages/gatsby-plugin-google-analytics/)
+-   ...and many more!
 
 Plugins also drive the new GraphQL data processing layer.
 

docs/blog/2017-07-19-creating-a-blog-with-gatsby/index.md

@@ -71,12 +71,12 @@ growing, so oftentimes a plugin already exists that solves the particular
 problem you're trying to solve. To address the functionality you want for _this_
 blog, you can use the following plugins:
 
-- [`gatsby-plugin-catch-links`][`gatsby-plugin-catch-links`]
-  - implements the history `pushState` API and does not require a page reload
-    on navigating to a different page in the blog
-- [`gatsby-plugin-react-helmet`][`gatsby-plugin-react-helmet`]
-  - [react-helmet][react-helmet] is a tool that allows for modification of the
-    `head` tags; Gatsby statically renders any of these `head` tag changes
+-   [`gatsby-plugin-catch-links`][`gatsby-plugin-catch-links`]
+    -   implements the history `pushState` API and does not require a page reload
+        on navigating to a different page in the blog
+-   [`gatsby-plugin-react-helmet`][`gatsby-plugin-react-helmet`]
+    -   [react-helmet][react-helmet] is a tool that allows for modification of the
+        `head` tags; Gatsby statically renders any of these `head` tag changes
 
 with the following command:
 
@@ -163,13 +163,13 @@ over and convert to usable HTML.
 You only need one transformer plugin (for Markdown), so let's get that
 installed.
 
-- [`gatsby-transformer-remark`][`gatsby-transformer-remark`]
-  - Uses the [remark][remark] Markdown parser to transform .md files on disk
-    into HTML; additionally, this transformer can optionally take plugins to
-    further extend functionality--e.g. add syntax highlighting with
-    `gatsby-remark-prismjs`, `gatsby-remark-copy-linked-files` to copy relative
-    files specified in markdown, `gatsby-remark-images` to compress images and
-    add responsive images with `srcset`, etc.
+-   [`gatsby-transformer-remark`][`gatsby-transformer-remark`]
+    -   Uses the [remark][remark] Markdown parser to transform .md files on disk
+        into HTML; additionally, this transformer can optionally take plugins to
+        further extend functionality--e.g. add syntax highlighting with
+        `gatsby-remark-prismjs`, `gatsby-remark-copy-linked-files` to copy relative
+        files specified in markdown, `gatsby-remark-images` to compress images and
+        add responsive images with `srcset`, etc.
 
 The process should be familiar by now, install and then add to config.
 
@@ -618,11 +618,11 @@ following along with this tutorial! You can not only make it pretty and style
 with CSS (or [styled-components][styled-components]!), but you could improve it
 functionally by implementing some of the following:
 
-- Add a tag listing and tag search page
-  - hint: the `createPages` API in `gatsby-node.js` file is useful here, as is
-    frontmatter
-- adding navigation between a specific blog post and past/present blog posts
-  (the `context` API of `createPages` is useful here), etc.
+-   Add a tag listing and tag search page
+    -   hint: the `createPages` API in `gatsby-node.js` file is useful here, as is
+        frontmatter
+-   adding navigation between a specific blog post and past/present blog posts
+    (the `context` API of `createPages` is useful here), etc.
 
 With your new found knowledge of Gatsby and its API, you should feel empowered to
 begin to utilize Gatsby to its fullest potential. A blog is just the starting
@@ -636,33 +636,51 @@ Now go build something great.
 
 ## Links
 
-- [`@dschau/gatsby-blog-starter-kit`][source-code]
-  - A working repo demonstrating all of the aforementioned functionality of
-    Gatsby
-- [`@dschau/create-gatsby-blog-post`][create-gatsby-blog-post]
-  - A utility and CLI I created to scaffold out a blog post following the
-    predefined Gatsby structure with frontmatter, date, path, etc.
-- [Source code for my blog][blog-source-code]
-  - The source code for my blog, which takes the `gatsby-starter-blog-post`
-    (previous link), and expands upon it with a bunch of features and some more
-    advanced functionality
+-   [`@dschau/gatsby-blog-starter-kit`][source-code]
+    -   A working repo demonstrating all of the aforementioned functionality of
+        Gatsby
+-   [`@dschau/create-gatsby-blog-post`][create-gatsby-blog-post]
+    -   A utility and CLI I created to scaffold out a blog post following the
+        predefined Gatsby structure with frontmatter, date, path, etc.
+-   [Source code for my blog][blog-source-code]
+    -   The source code for my blog, which takes the `gatsby-starter-blog-post`
+        (previous link), and expands upon it with a bunch of features and some more
+        advanced functionality
 
 [react-dom-server]: https://facebook.github.io/react/docs/react-dom-server.html
+
 [`gatsby-release`]: /blog/gatsby-v1/
+
 [`gatsby-plugins`]: /docs/plugins/
+
 [`gatsby-plugin-catch-links`]: /packages/gatsby-plugin-catch-links/
+
 [`gatsby-plugin-react-helmet`]: /packages/gatsby-plugin-react-helmet/
+
 [`gatsby-plugin-preact`]: /packages/gatsby-plugin-preact/
+
 [`gatsby-transformer-remark`]: /packages/gatsby-transformer-remark/
+
 [remark]: https://github.com/wooorm/remark
+
 [`gatsby-source-filesystem`]: /packages/gatsby-source-filesystem/
+
 [react-helmet]: https://github.com/nfl/react-helmet
+
 [frontmatter]: https://jekyllrb.com/docs/frontmatter/
+
 [learn-graphql]: https://www.howtographql.com
+
 [node-spec]: /docs/node-apis/
+
 [`gatsby-actions`]: /docs/actions/
+
 [styled-components]: https://github.com/styled-components/styled-components
+
 [yarn]: https://yarnpkg.com/en/
+
 [source-code]: https://github.com/dschau/gatsby-blog-starter-kit
+
 [blog-source-code]: https://github.com/dschau/blog
+
 [create-gatsby-blog-post]: https://github.com/DSchau/create-gatsby-blog-post

docs/blog/2017-09-13-why-is-gatsby-so-fast/index.md

@@ -142,17 +142,17 @@ high on the Annoying UX metric.
 
 #### Speed Index
 
-- 8098 — CNN.com
-- 5568 — downy.com
-- 7649 — washingtonpost.com
-- 2365 — gatsbyjs.org
+-   8098 — CNN.com
+-   5568 — downy.com
+-   7649 — washingtonpost.com
+-   2365 — gatsbyjs.org
 
 #### Time to Interactive
 
-- 32.1s — CNN.com
-- 14.2s — downy.com
-- 31.4s — washingtonpost.com
-- 4.4s — gatsbyjs.org
+-   32.1s — CNN.com
+-   14.2s — downy.com
+-   31.4s — washingtonpost.com
+-   4.4s — gatsbyjs.org
 
 ![reactnext-gatsby-performance.038](reactnext-gatsby-performance.038.png)
 

docs/blog/2017-09-18-gatsby-modern-static-generation/index.md

@@ -21,20 +21,20 @@ production by creating a landing page very fast.
 
 Static site generators like Jekyll all work pretty similarly:
 
-- Describe your content in some common templating language ([Pug](http://pugjs.org),
-  [Handlebars](http://handlebarsjs.com), etc)
-- While in development, start a local web server and add file "watchers" that
-  will listen for content changes and re-render the site
-- Finally, render the whole site in static HTML and deploy. The generator will
-  combine your files and produce a well formed HTML content.
+-   Describe your content in some common templating language ([Pug](http://pugjs.org),
+    [Handlebars](http://handlebarsjs.com), etc)
+-   While in development, start a local web server and add file "watchers" that
+    will listen for content changes and re-render the site
+-   Finally, render the whole site in static HTML and deploy. The generator will
+    combine your files and produce a well formed HTML content.
 
 Let's say you navigate to the good old site example.com:
 
-- The browser requests the page at example.com
-- The server responds with the HTML content
-- The browser renders the page and loads the asset related to the script tag
-- JS will instruct the browser to manipulate the DOM, for example, to show a
-  "welcome to this page" popup dialog.
+-   The browser requests the page at example.com
+-   The server responds with the HTML content
+-   The browser renders the page and loads the asset related to the script tag
+-   JS will instruct the browser to manipulate the DOM, for example, to show a
+    "welcome to this page" popup dialog.
 
 A caveat here is that you have to keep the client side logic separated from the
 backend. The client side JS file that shows the modal dialog has nothing to do
@@ -73,29 +73,29 @@ If you use React with
 [server-side rendering](https://facebook.github.io/react/docs/react-dom-server.html),
 your flow looks something like this:
 
-- A browser requests a page
-- The server responds with static HTML
-- The browser immediately renders the page so the user can see it
-- The browser loads additional JS in the background
-- The client takes some action, like navigating to a different route.
-- The browser uses the additional JS to handle this action.
+-   A browser requests a page
+-   The server responds with static HTML
+-   The browser immediately renders the page so the user can see it
+-   The browser loads additional JS in the background
+-   The client takes some action, like navigating to a different route.
+-   The browser uses the additional JS to handle this action.
 
 On your end, the development flow looks:
 
-- Describe your content in React Components
-- During development, write code like a boss (hot reloading, modularized code,
-  webpack plugins, etc...)
-- Use React Server Side Rendering API to convert this code to static HTML
-  content, and JavaScript code, on your server
+-   Describe your content in React Components
+-   During development, write code like a boss (hot reloading, modularized code,
+    webpack plugins, etc...)
+-   Use React Server Side Rendering API to convert this code to static HTML
+    content, and JavaScript code, on your server
 
 It's really that easy? Well, sort of.
 
 There is the need for a strong abstraction that will…
 
-- track your links across your components
-- parse content written in another format, like blog posts written in Markdown
-- generate code that will not bloat the client and will efficiently serve the
-  content to the user.
+-   track your links across your components
+-   parse content written in another format, like blog posts written in Markdown
+-   generate code that will not bloat the client and will efficiently serve the
+    content to the user.
 
 Thankfully, there are a few projects that took the initiative on this:
 [Gatsby](/), [Phenomic](https://phenomic.io), and
@@ -149,8 +149,8 @@ You can try it yourself by cloning the
 [source code](https://github.com/kbariotis/kostasbariotis.com) and after
 installing dependencies, run:
 
-- `npm run develop` to fire up the development server
-- `npm run build` to build the site (check the `/public` folder after it's done)
+-   `npm run develop` to fire up the development server
+-   `npm run build` to build the site (check the `/public` folder after it's done)
 
 ## An alternative to HTML caching
 
@@ -177,11 +177,11 @@ WordPress's MySQL database.
 
 To conclude, Gatsby will allow us to:
 
-- serve static content without maintaining complex stacks
-- keep a clear separation between content and the presentation layer
-- have cool features like client side routing and hot reload on development, out
-  of the box
-- reuse the same code that is being used to generate the backend content at our
-  visitors' browsers
+-   serve static content without maintaining complex stacks
+-   keep a clear separation between content and the presentation layer
+-   have cool features like client side routing and hot reload on development, out
+    of the box
+-   reuse the same code that is being used to generate the backend content at our
+    visitors' browsers
 
 I hope you will experiment with Gatsby, and let me know what you think!