Upgrade prettier to 1.12.1 and run format (#5040)

* Upgrade prettier to 1.12.1 and run format

* Update snapshot

README.md

@@ -198,7 +198,7 @@ Websites built with Gatsby:
   ([source](https://github.com/HaoZeke/hbtuMun18))
 * [The Audacious Project](https://audaciousproject.org/)
 * [upGizmo](https://www.upgizmo.com/)
-* [The Bastion Bot](https://bastionbot.org/ 'The Bastion Bot')
+* [The Bastion Bot](https://bastionbot.org/ "The Bastion Bot")
 * [Yuuniworks](https://www.yuuniworks.com/) ([source](https://github.com/junkboy0315/yuuni-web))
 * [Chin Loong Tan - Blog/Portfolio](https://chinloongtan.com/)
 * [F1 Vision](https://f1vision.com/)

docs/blog/2017-10-16-making-website-building-fun/index.md

@@ -227,12 +227,12 @@ before we get to actually coding the frontend.
 
 For example, how does a single image typically get on a website?
 
-1. A page is designed
-2. Specific images are chosen
-3. The images are resized (with ideally multiple thumbnails to fit different
-   devices)
-4. And finally, the image(s) are included in the HTML/CSS/JS (or React
-   component) for the page.
+1.  A page is designed
+2.  Specific images are chosen
+3.  The images are resized (with ideally multiple thumbnails to fit different
+    devices)
+4.  And finally, the image(s) are included in the HTML/CSS/JS (or React
+    component) for the page.
 
 What makes gatsby-image really interesting is it's _seamlessly integrated into
 Gatsby's data layer_ which has native image processing capabilities.
@@ -278,10 +278,10 @@ export const query = graphql`
 So instead of a long pipeline of tasks to setup optimized images for your site,
 the steps now are:
 
-1. Install gatsby-image
-2. Decide what size of image you need (125x125 in the example above)
-3. Add your query and the gatsby-image component to your page
-4. And… that's it!
+1.  Install gatsby-image
+2.  Decide what size of image you need (125x125 in the example above)
+3.  Add your query and the gatsby-image component to your page
+4.  And… that's it!
 
 Now playing with images is fun! Want to tweak your design? No problem, just
 change your query a bit and see how the page updates. By eliminating the

docs/blog/2017-10-17-building-i18n-with-gatsby/index.md

@@ -298,22 +298,22 @@ To let it render the content into html, you need to load i18n namespaces (using
 ```js
 // gatsby-ssr.js
 
-import React from 'react'
-import { Provider } from 'react-redux'
-import { renderToString } from 'react-dom/server'
-import i18n from './src/i18n'
+import React from "react";
+import { Provider } from "react-redux";
+import { renderToString } from "react-dom/server";
+import i18n from "./src/i18n";
 
-import createStore from './src/state/createStore'
+import createStore from "./src/state/createStore";
 
 exports.replaceRenderer = ({ bodyComponent, replaceBodyHTMLString }) => {
-  i18n.loadNamespaces(['common'], () => {
-    const store = createStore()
+  i18n.loadNamespaces(["common"], () => {
+    const store = createStore();
     const ConnectedBody = () => (
       <Provider store={store}>{bodyComponent}</Provider>
-    )
-    replaceBodyHTMLString(renderToString(<ConnectedBody />))
-  })
-}
+    );
+    replaceBodyHTMLString(renderToString(<ConnectedBody />));
+  });
+};
 ```
 
 ### Without redux
@@ -323,17 +323,17 @@ exports.replaceRenderer = ({ bodyComponent, replaceBodyHTMLString }) => {
 ```js
 // gatsby-ssr.js
 
-import React from 'react'
-import { renderToString } from 'react-dom/server'
-import i18n from './src/i18n'
+import React from "react";
+import { renderToString } from "react-dom/server";
+import i18n from "./src/i18n";
 
-import createStore from './src/state/createStore'
+import createStore from "./src/state/createStore";
 
 exports.replaceRenderer = ({ bodyComponent, replaceBodyHTMLString }) => {
-  i18n.loadNamespaces(['common'], () => {
-    replaceBodyHTMLString(bodyComponent)
-  })
-}
+  i18n.loadNamespaces(["common"], () => {
+    replaceBodyHTMLString(bodyComponent);
+  });
+};
 ```
 
 > `translate` hoc from react-i18next cause page / component not able to SSR. I make it works by import i18n & use i18n.t

docs/blog/2018-01-22-getting-started-gatsby-and-wordpress/index.md

@@ -136,8 +136,8 @@ While this isn't a tutorial -- more a guided walkthrough of me familiarizing and
 
 ##Sidenotes
 
-1. You [don't need to know GraphQL](https://github.com/gatsbyjs/gatsby/issues/1172#issuecomment-308634739) to get started with Gatsby. I didn't. It's been a good introduction.
-2. Gatsby makes heavy use of [plugins](/docs/plugins/) — both official and community — for a lot of things, from one that implements [Google Analytics](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-plugin-google-analytics), to one that adds [GitHub's accessibility error scanner](https://github.com/alampros/gatsby-plugin-accessibilityjs) to all pages.
-3. Read through some of the source code. I particularly enjoyed reading through [the bootstrap process](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/bootstrap/index.js). (It's beautifully commented).
-4. Gatsby.js is a static Progressive Web App (PWA) generator, but to be PWA friendly (at least according to the [Lighthouse PWA audit](https://developers.google.com/web/tools/lighthouse/)), look into two plugins: `gatsby-plugin-manifest` and `gatsby-plugin-offline`.
-5. I did end up [deploying with Netlify](/docs/deploy-gatsby/#netlify), and I'm super happy with it. (A [previous post](/blog/2017-12-06-gatsby-plus-contentful-plus-netlify/#solution-netlify--gatsby) discussed Netlify a bit more, if you're interested).
+1.  You [don't need to know GraphQL](https://github.com/gatsbyjs/gatsby/issues/1172#issuecomment-308634739) to get started with Gatsby. I didn't. It's been a good introduction.
+2.  Gatsby makes heavy use of [plugins](/docs/plugins/) — both official and community — for a lot of things, from one that implements [Google Analytics](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-plugin-google-analytics), to one that adds [GitHub's accessibility error scanner](https://github.com/alampros/gatsby-plugin-accessibilityjs) to all pages.
+3.  Read through some of the source code. I particularly enjoyed reading through [the bootstrap process](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/bootstrap/index.js). (It's beautifully commented).
+4.  Gatsby.js is a static Progressive Web App (PWA) generator, but to be PWA friendly (at least according to the [Lighthouse PWA audit](https://developers.google.com/web/tools/lighthouse/)), look into two plugins: `gatsby-plugin-manifest` and `gatsby-plugin-offline`.
+5.  I did end up [deploying with Netlify](/docs/deploy-gatsby/#netlify), and I'm super happy with it. (A [previous post](/blog/2017-12-06-gatsby-plus-contentful-plus-netlify/#solution-netlify--gatsby) discussed Netlify a bit more, if you're interested).

docs/blog/2018-03-07-why-we-created-the-plugin-library/index.md

@@ -23,10 +23,10 @@ This map reflects how it took most people a lot of time browsing through the plu
 
 With the empathy map and the interviews as our guide, we learned that most people want to:
 
-1. Find the best, most recent, and relevant plugin, library, or component for their site.
-2. Learn how to build a plugin.
-3. Preview plugin functionality before installation.
-4. Share plugins with others.
+1.  Find the best, most recent, and relevant plugin, library, or component for their site.
+2.  Learn how to build a plugin.
+3.  Preview plugin functionality before installation.
+4.  Share plugins with others.
 
 ## Learning from other plugin libraries
 

docs/blog/2018-03-29-migration-from-wordpress-to-gatsby/index.md

@@ -76,7 +76,7 @@ Gatsby also works great with images, which are usually a big hit to site's perfo
 
 I think Gatsby is great. I had a lot of fun using it so far and I've learned much in the process. It offers you freedom and flexibility. However, it is not as mature as some of the competitors. This is improving quickly as it is under rapid development. Still, I did encounter some bugs complicating my development. On the other hand, the community was really helpful and supportive. Some of the features, which I would consider standard were not yet available or sufficient such as tags and categories support, pagination or Open Graph metadata. I would also like to see AsciiDoc support instead of just plain Markdown. One of the biggest problems was probably the lack of visual themes. For a long time, there was not any official themes directory. In Feb 2018 [Gatsby Manor was launched](/blog/2018-02-09-announcing-gatsby-manor-themes-for-gatsbyjs/) and now it contains just SIX themes, which are all only ports of [HTML5 UP themes](https://html5up.net/). However, with the current development rate, I am sure more and more plugins will be available out of the box shortly.
 
-## Results  
+## Results
 
 Overall I am really happy with Gatsby and the migration from WordPress. I no longer fear my WordPress will get compromised. Everything is now on GitHub and under version control. It's much more transparent. No longer need of database backups and rollbacks are now easy in case of something goes wrong. Not to mention the possibility of developing new features safely in branches and deploying and testing them separately from the 'production' environment. And no more fees for hosted WordPress. And writing in markdown is also more convenient for me as I don't focus on HTML or visuals when writing but rather on the content.
 

docs/blog/2018-04-06-introducing-gatsby-rfc-process/index.md

@@ -4,15 +4,15 @@ author: Kyle Mathews
 date: "2018-04-06"
 ---
 
-We're adopting an RFC ("request for comments") process for contributing ideas to Gatsby. 
+We're adopting an RFC ("request for comments") process for contributing ideas to Gatsby.
 
 Inspired by [React](https://github.com/reactjs/rfcs), [Yarn](https://github.com/yarnpkg/rfcs), [Ember](https://github.com/emberjs/rfcs), and [Rust](https://github.com/rust-lang/rfcs), the goal is to allow Gatsby core team members and community members to collaborate on the design of new features. It's also intended to provide a clear path for ideas to enter the project:
 
-- Create an RFC document detailing your proposal.
-- Submit a PR to the [RFC repository](https://github.com/gatsbyjs/rfcs).
-- Incorporate feedback into the proposal.
-- After discussion, the core team may or may not accept the RFC.
-- If the RFC is accepted, the PR is merged.
+* Create an RFC document detailing your proposal.
+* Submit a PR to the [RFC repository](https://github.com/gatsbyjs/rfcs).
+* Incorporate feedback into the proposal.
+* After discussion, the core team may or may not accept the RFC.
+* If the RFC is accepted, the PR is merged.
 
 RFCs are accepted when they are approved for implementation in Gatsby. A more thorough description of the process is available in the repository's [README](https://github.com/gatsbyjs/rfcs/blob/master/README.md). The exact details may be refined in the future.
 

docs/blog/2018-04-10-how-to-handle-comments-in-gatsby-blogs/index.md

@@ -3,7 +3,7 @@ title: How to handle comments in Gatsby blogs
 date: "2018-04-09"
 author: "Gatsby Central"
 canonicalLink: https://www.gatsbycentral.com/how-to-handle-comments-in-gatsby-blogs
-publishedAt: "Gatsby Central" 
+publishedAt: "Gatsby Central"
 ---
 
 > tl;dr Hosted services like disqus are the easiest. Staticman is the best option, but requires some setup.

docs/blog/2018-04-11-trying-out-gatsby-at-work-and-co/index.md

@@ -19,9 +19,9 @@ Our project was to build a new website for [Whittle School & Studios](https://ww
 
 We had a blast building the site, and learned a lot about Gatsby in the process. This post will take you through the different parts of our journey:
 
-- [Choosing a stack](#choosing-a-stack)
-- [Creating a Gatsby workflow](#creating-a-gatsby-workflow)
-- [Contributing to Gatsby](#contributing-to-gatsby)
+* [Choosing a stack](#choosing-a-stack)
+* [Creating a Gatsby workflow](#creating-a-gatsby-workflow)
+* [Contributing to Gatsby](#contributing-to-gatsby)
 
 ## Choosing a stack
 
@@ -37,7 +37,7 @@ As a content-heavy site, the project would need a CMS. Our choice here was [Cont
 
 We also knew that the site would eventually need to launch in both the US and China. This came with a bunch of unknowns on the China side of things: Could we rely on the same build system and CDN for all locales, or would China require a unique setup to account for server performance discrepancies and possible API restrictions?
 
-We didn’t know, and we weren’t going to know for some time, because most of these decisions were going to be made by an external vendor. Not wanting to back ourselves into a corner, we decided to use a static site generator. No matter what devops we wound up with, we could bank on compiling static files and putting them *somewhere*.
+We didn’t know, and we weren’t going to know for some time, because most of these decisions were going to be made by an external vendor. Not wanting to back ourselves into a corner, we decided to use a static site generator. No matter what devops we wound up with, we could bank on compiling static files and putting them _somewhere_.
 
 All of this begged the question: “What’s a good static site generator that works with Contentful?”
 
@@ -51,7 +51,7 @@ Gatsby is built on React, something our team already knows and likes. We use Rea
 
 #### Prefetched pages ⚡️
 
-When we decided to use a static site generator, we assumed we’d be building a classic *static site*, with each route change requesting brand new HTML from the server. For a small, simple site, we thought this was good enough, but Gatsby gave us one better: pre-fetching, out of the box. This meant that our site would feel like a single page app while still benefiting from the flexibility and improved performance of a static site.
+When we decided to use a static site generator, we assumed we’d be building a classic _static site_, with each route change requesting brand new HTML from the server. For a small, simple site, we thought this was good enough, but Gatsby gave us one better: pre-fetching, out of the box. This meant that our site would feel like a single page app while still benefiting from the flexibility and improved performance of a static site.
 
 #### Contentful support
 
@@ -261,13 +261,13 @@ If you’re nervous about contributing to a library, do what I did: make a reall
 
 ### Reading the documentation
 
-We developers often take pride in how far we’re able to get *without* reading the documentation — at least I know I do — but, as I came to make subsequent PRs to Gatsby, I found the [contributor guidelines](https://github.com/gatsbyjs/gatsby/blob/master/CONTRIBUTING.md) to be incredibly helpful.
+We developers often take pride in how far we’re able to get _without_ reading the documentation — at least I know I do — but, as I came to make subsequent PRs to Gatsby, I found the [contributor guidelines](https://github.com/gatsbyjs/gatsby/blob/master/CONTRIBUTING.md) to be incredibly helpful.
 
 In particular, the documentation will show you how to use your local Gatsby clone and [gatsby-dev-cli](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-dev-cli) to:
 
-- Watch for your local changes to Gatsby packages
-- Recompile packages on-the-fly
-- Copy these packages into your project’s `node_modules` folder to test as you go
+* Watch for your local changes to Gatsby packages
+* Recompile packages on-the-fly
+* Copy these packages into your project’s `node_modules` folder to test as you go
 
 If you’ve ever used `yarn link` to modify a dependency locally, this provides a similar experience.
 
@@ -287,9 +287,9 @@ Gatsby, however, uses a monorepo architecture, so pushing up a fork with a chang
 
 Our workaround was to create a new repo for the package in question and push the build directly to Github. Here’s how it would work if you were making an update to, say, `gatsby-source-contentful`:
 
-- Go to your local fork of Gatsby, on the branch with your changes, and run `yarn watch` to compile a built version of your modified package.
-- Copy that package to a new directory `cp -a packages/gatsby-source-contentful path-to-my-repo`
-- Push the contents of this directory to Github and link it in your `package.json` as usual.
+* Go to your local fork of Gatsby, on the branch with your changes, and run `yarn watch` to compile a built version of your modified package.
+* Copy that package to a new directory `cp -a packages/gatsby-source-contentful path-to-my-repo`
+* Push the contents of this directory to Github and link it in your `package.json` as usual.
 
 ## Following up
 

docs/blog/2018-1-18-strapi-and-gatsby/index.md

@@ -110,10 +110,10 @@ Strapi APIs are based on a data structure called Content Types (equivalent of mo
 
 Add some articles in the database. To do so, follow these instructions:
 
-1. Visit the [articles list page](http://localhost:1337/admin/plugins/content-type-builder/models/article).
-2. Click on `Add New Article`.
-3. Insert values, link to an author and submit the form.
-4. Create two other articles.
+1.  Visit the [articles list page](http://localhost:1337/admin/plugins/content-type-builder/models/article).
+2.  Click on `Add New Article`.
+3.  Insert values, link to an author and submit the form.
+4.  Create two other articles.
 
 ![Tutorial](strapi-content-manager.png)
 

docs/blog/2018-1-25-building-a-site-with-react-and-contentful/index.md

@@ -194,9 +194,7 @@ export default ({ data }) => {
           {trick.node.exampleOfTheCommandInAction && (
             <img src={trick.node.exampleOfTheCommandInAction[0].file.url} />
           )}
-          {trick.node.exampleOfTheCommandInAction && (
-            <p>{trick.node.exampleOfTheCommandInAction[0].description}</p>
-          )}
+          {trick.node.exampleOfTheCommandInAction && <p>{trick.node.exampleOfTheCommandInAction[0].description}</p>}
         </div>
       ))}
     </div>

docs/blog/2018-2-27-why-i-upgraded-my-website-to-gatsbyjs-from-jekyll/index.md

@@ -54,7 +54,12 @@ For example, I defined a `PostTemplate` which will be used to render pages for a
 import React from "react";
 
 export default function PostTemplate({
-  data: { markdownRemark: { frontmatter: { title, date }, html } },
+  data: {
+    markdownRemark: {
+      frontmatter: { title, date },
+      html,
+    },
+  },
 }) {
   return (
     <div>

docs/blog/2018-2-6-choosing-a-back-end/index.md

@@ -37,10 +37,10 @@ Now we need a system to manage and deliver our content in a nice API (instructed
 
 Firstly, though, why do we want a Headless CMS and a JAMstack for the project? There are a few reasons most people use them, and some that are down to personal preference:
 
-1. **Easy setup!**
-2. **No back-end code.** I’m a front-end dev and honestly don’t want to spend hours setting up some PHP that I won’t enjoy. Gimme the good stuff.
-3. **No server needed.** Cloud CMSs mean that I don’t need to pay the hosting people to setup an SQL database.
-4. **Easy to edit.** If I need to edit a site on the fly or have a client who needs to do the same, they don’t need to touch any code or run to their home workstation to fix a spelling error. They can access it anywhere.
+1.  **Easy setup!**
+2.  **No back-end code.** I’m a front-end dev and honestly don’t want to spend hours setting up some PHP that I won’t enjoy. Gimme the good stuff.
+3.  **No server needed.** Cloud CMSs mean that I don’t need to pay the hosting people to setup an SQL database.
+4.  **Easy to edit.** If I need to edit a site on the fly or have a client who needs to do the same, they don’t need to touch any code or run to their home workstation to fix a spelling error. They can access it anywhere.
 
 ---