Update yarn.lock + prettier

.github/ISSUE_TEMPLATE/question.md

@@ -20,18 +20,19 @@ about: Usage question or discussion about Gatsby.
 
 ## Summary
 
-
 ## Relevant information
-<!-- Provide as much useful information as you can -->
 
+<!-- Provide as much useful information as you can -->
 
 ### Environment (if relevant)
-* Gatsby version (`npm list gatsby`):
-* gatsby-cli version (`gatsby --version`):
-* Node.js version:
-* Operating System:
+
+- Gatsby version (`npm list gatsby`):
+- gatsby-cli version (`gatsby --version`):
+- Node.js version:
+- Operating System:
 
 ### File contents (if changed)
+
 `gatsby-config.js`: N/A <!-- Please use a code block or just leave it as is if wasn't changed -->
 `package.json`: N/A <!-- Please use a code block or just leave it as is if wasn't changed -->
 `gatsby-node.js`: N/A <!-- Please use a code block or just leave it as is if wasn't changed -->

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 brocurewares to complex
+- **universal**, work for all types of sites from simple brocurewares to complex
   web-apps.
-* **simple**, not requiring any setup to start using and with thoughtful APIs to
+- **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
+- **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
+- **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
+- **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
+- **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
+- **internet scale**, launch your site to millions without crashing your site
   (or your wallet).
-* **secure**, doesn't put your your users' data at risk of hacking.
+- **secure**, doesn't put your 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
+- 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 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-05-31-introduction-to-gatsby/index.md

@@ -13,27 +13,33 @@ In case you haven’t heard about it, Gatsby is the latest hot thing in static s
 Having never used an SSG before (although I’ve read about them), and with very limited experience with React, what better way to dip my toe into the water than using Gatsby to publish my brand new blog [CSS {In Real Life}](https://css-irl.info/)?
 
 ### Getting started
+
 It turns out that getting started with Gatsby is pretty easy. The Gatsby site features a fantastic, step-by-step tutorial that walks you through getting your first site up and running (even down to deploying), and contains a wealth of resources for when you’ve mastered the basics. You don’t need any prior experience with React, although working with Gatsby definitely made me want to learn React to take full advantage of its power.
 
-One thing that prohibits me from publishing side projects is the thought of configuring a whole build setup with Gulp, webpack, etc. just for something small. This is where Gatsby really appeals to me. Gatsby provides an entire out-of-the-box build setup. Yep. Run `gatsby develop` and immediately you can bypass all that configuration and start building cool stuff in the browser (with live reloads). Run `gatsby build` and your production code is optimised (including progressive image loading and code splitting, among many other features) with *absolutely no effort on your part whatsoever*. You could feasibly get a small, performant site built and deployed in just minutes. You can also add a custom webpack config if you need to.
+One thing that prohibits me from publishing side projects is the thought of configuring a whole build setup with Gulp, webpack, etc. just for something small. This is where Gatsby really appeals to me. Gatsby provides an entire out-of-the-box build setup. Yep. Run `gatsby develop` and immediately you can bypass all that configuration and start building cool stuff in the browser (with live reloads). Run `gatsby build` and your production code is optimised (including progressive image loading and code splitting, among many other features) with _absolutely no effort on your part whatsoever_. You could feasibly get a small, performant site built and deployed in just minutes. You can also add a custom webpack config if you need to.
 
 ### CSS
+
 There are two options when it comes to writing CSS for your components: CSS-in-JS (using libraries such as Glamor and Styled Components) or [CSS Modules](https://github.com/css-modules/css-modules). As I feel far more comfortable writing “traditional” CSS, I opted for the latter. CSS Modules are really interesting, and not tied to Gatsby. Styles are scoped locally by default and unique class names are generated programmatically, meaning you don’t get the clashes with naming and specificity that you sometimes get in traditional CSS, and you can compose new selectors from others. I feel like I’ve only scratched the surface of CSS Modules, and am looking forward to experimenting further.
 
-*(Side note: This doesn’t mean I have a problem with traditional CSS, or that I’m advocating CSS Modules in every scenario! Many of the so-called “problems” of CSS are actually down to misuse or misapplication. Nevertheless, CSS Modules and CSS-in-JS are good to know about, and can be useful tools to have in your arsenal.)*
+_(Side note: This doesn’t mean I have a problem with traditional CSS, or that I’m advocating CSS Modules in every scenario! Many of the so-called “problems” of CSS are actually down to misuse or misapplication. Nevertheless, CSS Modules and CSS-in-JS are good to know about, and can be useful tools to have in your arsenal.)_
 
 ### Plugins
+
 There is a whole ecosystem of Gatsby plugins that you can pick and choose to tailor your project. I’m using `gatsby-plugin-sass` to enable me to write Sass instead of regular CSS, `gatsby-transformer-remark` for markdown files and `gatsby-plugin-typography` which sets you up with some nice typography combos with minimal configuration. Authoring your own plugins and contributing to the Gatsby community is encouraged, if that’s your bag.
 
 ### Data
+
 You could of course hard code all your content, but it’s likely you’ll want some sort of dynamic content on your site.
 
 Gatsby’s data layer is powered by GraphQL, and the tutorial walks through how to build database queries with Gatsby’s GraphiQL tool. It’s very visual, showing you exactly what your database queries will return, which for someone like me (who finds anything database-related a little scary) is a blessing.
 
 I write my blog posts in markdown files, but you could configure Gatsby to work with Github Pages, or the CMS of your choice for a better editorial experience.
 
 ### Deployment
+
 After you’ve run the build command, Gatsby allows near-instantaneous deployment through [Surge](https://surge.sh/), [Netlify](https://www.netlify.com/) and others. I set up my hosting with Netlify – run `gatsby deploy`, set up a Netlify account and you’re good to go. You can then configure Netlify to auto-deploy whenever you push to a repository. Netlify provides a simpler and more helpful experience than other hosting providers I’ve used, with helpful documentation, taking all the stress away from launching a site!
 
 ### In conclusion
+
 I thoroughly recommend giving Gatsby a go if you’re on the fence about trying a static site generator and want to get a simple site up and running quickly and easily. The amount of thought that’s gone into every aspect of the onboarding process and the developer experience is absolutely fantastic. And, have just received a shed load of seed money to launch as a startup, it’s only going to get better.

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

@@ -74,11 +74,11 @@ growing, so oftentimes a plugin already exists that solves the particular
 problem you're trying to solve. To address the functionality we want for _this_
 blog, we'll use the following plugins:
 
-* [`gatsby-plugin-catch-links`][gatsby-plugin-catch-links]
-  * implements the history `pushState` API, and does not require a page reload
+- [`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
+- [`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:
@@ -165,8 +165,8 @@ over and convert to usable HTML.
 We'll only be using 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
+- [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
@@ -607,10 +607,10 @@ 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
+- 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
+- adding navigation between a specific blog post and past/present blog posts
   (the `context` API of `createPages` is useful here), etc.
 
 With our new found knowledge of Gatsby and its API, you should feel empowered to
@@ -625,14 +625,14 @@ Now go build something great.
 
 ## Links
 
-* [`@dschau/gatsby-blog-starter-kit`][source-code]
-  * A working repo demonstrating all of the aforementioned functionality of
+- [`@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
+- [`@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
+- [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
 

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,19 +21,19 @@ 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),
+- 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
+- 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
+- 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
+- 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
@@ -73,28 +73,28 @@ 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.js Components
-* During development, write code like a boss (hot reloading, modularized code,
+- Describe your content in React.js Components
+- During development, write code like a boss (hot reloading, modularized code,
   webpack plugins, etc...)
-* Use React.js Server Side Rendering API to convert this code to static HTML
+- Use React.js 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
+- 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:
@@ -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
+- 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
+- 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!