chore(docs): Use soft wraps for old docs (#20887)

* fix-docs/docs/api-proxy

* fix-docs/docs/api-specification

* fix-docs/docs/babel-plugin-macros

* fix-docs/docs/babel

* fix-docs/docs/browser-support

* fix-docs/docs/best-practices-for-orgs

docs/docs/api-proxy.md

@@ -8,11 +8,9 @@ If you’re not familiar with Gatsby’s lifecycle, see the overview [Gatsby Lif
 
 ## Proxying API requests in development
 
-People often serve the frontend React app from the same host and port as their
-backend implementation.
+People often serve the frontend React app from the same host and port as their backend implementation.
 
-To tell the development server to proxy any unknown requests to your API server
-in development, add a `proxy` field to your `gatsby-config.js`, for example:
+To tell the development server to proxy any unknown requests to your API server in development, add a `proxy` field to your `gatsby-config.js`, for example:
 
 ```javascript:title=gatsby-config.js
 module.exports = {
@@ -40,18 +38,13 @@ module.exports = {
 }
 ```
 
-This way, when you `fetch('/api/todos')` in development, the development server
-will recognize that it’s not a static asset, and will proxy your request to
-`http://dev-mysite.com/api/todos` as a fallback.
+This way, when you `fetch('/api/todos')` in development, the development server will recognize that it’s not a static asset, and will proxy your request to `http://dev-mysite.com/api/todos` as a fallback.
 
-Keep in mind that `proxy` only has effect in development (with `gatsby develop`), and it is up to you to ensure that URLs like `/api/todos` point to
-the right place in production.
+Keep in mind that `proxy` only has effect in development (with `gatsby develop`), and it is up to you to ensure that URLs like `/api/todos` point to the right place in production.
 
 ## Advanced proxying
 
-Sometimes you need more granular/flexible access to the development server.
-Gatsby exposes the [Express.js](https://expressjs.com/) development server to your site's `gatsby-config.js` where you
-can add Express middleware as needed.
+Sometimes you need more granular/flexible access to the development server. Gatsby exposes the [Express.js](https://expressjs.com/) development server to your site's `gatsby-config.js` where you can add Express middleware as needed.
 
 ```javascript:title=gatsby-config.js
 var proxy = require("http-proxy-middleware")

docs/docs/api-specification.md

@@ -2,12 +2,9 @@
 title: API Specification
 ---
 
-Gatsby's APIs are tailored conceptually to some extent after React.js to improve
-the coherence between the two systems.
+Gatsby's APIs are tailored conceptually to some extent after React.js to improve the coherence between the two systems.
 
-The two top priorities of the API are a) enable a broad and robust plugin
-ecosystem and b) on top of that a broad and robust theme ecosystem (themes are
-on the back burner btw until after v1 comes out).
+The two top priorities of the API are a) enable a broad and robust plugin ecosystem and b) on top of that a broad and robust theme ecosystem (themes are on the back burner btw until after v1 comes out).
 
 ## Prerequisites
 
@@ -19,62 +16,34 @@ Plugins can extend Gatsby in many ways:
 
 - Sourcing data (e.g. from the filesystem or an API or a database)
 - Transforming data from one type to another (e.g. a markdown file to HTML)
-- Creating pages (e.g. a directory of markdown files all gets turned into pages
-  with URLs derived from their file names).
-- Modifying webpack config (e.g. for styling options, adding support for other
-  compile-to-js languages)
-- Adding things to the rendered HTML (e.g. meta tags, analytics JS snippets like
-  Google Analytics)
-- Writing out things to build directory based on site data (e.g. service worker,
-  sitemap, RSS feed)
-
-A single plugin can use multiple APIs to accomplish its purpose. E.g. the plugin
-for the CSS-in-JS library [Glamor](/packages/gatsby-plugin-glamor/):
+- Creating pages (e.g. a directory of markdown files all gets turned into pages with URLs derived from their file names).
+- Modifying webpack config (e.g. for styling options, adding support for other compile-to-js languages)
+- Adding things to the rendered HTML (e.g. meta tags, analytics JS snippets like Google Analytics)
+- Writing out things to build directory based on site data (e.g. service worker, sitemap, RSS feed)
+
+A single plugin can use multiple APIs to accomplish its purpose. E.g. the plugin for the CSS-in-JS library [Glamor](/packages/gatsby-plugin-glamor/):
 
 1.  modifies the webpack config to add its plugin
 2.  adds a Babel plugin to replace React's default createElement
-3.  modifies server rendering to extract out the critical CSS for each rendered
-    page and inline the CSS in the `<head>` of that HTML page.
-
-Plugins can also depend on other plugins. [The Sharp
-plugin](/packages/gatsby-plugin-sharp/) exposes a number of high-level APIs for
-transforming images that several other Gatsby image plugins depend on.
-[gatsby-transformer-remark](/packages/gatsby-transformer-remark/) does basic
-markdown->html transformation but exposes an API to allow other plugins to
-intervene in the conversion process e.g.
-[gatsby-remark-prismjs](/packages/gatsby-remark-prismjs/) which adds
-highlighting to code blocks.
-
-Transformer plugins are decoupled from source plugins. Transformer plugins look
-at the media type of new nodes created by source plugins to decide if they can
-transform it or not. Which means that a markdown transformer plugin can
-transform markdown from any source without any other configuration e.g. from a
-file, a code comment, or external service like Trello which supports markdown
-in some of its data fields.
-
-See
-[the full list of (official only for now — adding support for community plugins later) plugins](/docs/plugins/).
+3.  modifies server rendering to extract out the critical CSS for each rendered page and inline the CSS in the `<head>` of that HTML page.
+
+Plugins can also depend on other plugins. [The Sharp plugin](/packages/gatsby-plugin-sharp/) exposes a number of high-level APIs for transforming images that several other Gatsby image plugins depend on. [gatsby-transformer-remark](/packages/gatsby-transformer-remark/) does basic markdown->html transformation but exposes an API to allow other plugins to intervene in the conversion process e.g. [gatsby-remark-prismjs](/packages/gatsby-remark-prismjs/) which adds highlighting to code blocks.
+
+Transformer plugins are decoupled from source plugins. Transformer plugins look at the media type of new nodes created by source plugins to decide if they can transform it or not. Which means that a markdown transformer plugin can transform markdown from any source without any other configuration e.g. from a file, a code comment, or external service like Trello which supports markdown in some of its data fields.
+
+See [the full list of (official only for now — adding support for community plugins later) plugins](/docs/plugins/).
 
 ## API
 
 ### Concepts
 
-- _Page_ — a site page with a pathname, a template component, and optional
-  GraphQL query.
-- _Page Component_ — React.js component that renders a page and can optionally
-  specify a GraphQL query
-- _Component extensions_ — extensions that are resolvable as components. `.js`
-  and `.jsx` are supported by core. But plugins can add support for other
-  compile-to-js languages.
-- _Dependency_ — Gatsby automatically tracks dependencies between different
-  objects e.g. a page can depend on certain nodes. This allows for hot
-  reloading, caching, incremental rebuilds, etc.
+- _Page_ — a site page with a pathname, a template component, and optional GraphQL query.
+- _Page Component_ — React.js component that renders a page and can optionally specify a GraphQL query
+- _Component extensions_ — extensions that are resolvable as components. `.js` and `.jsx` are supported by core. But plugins can add support for other compile-to-js languages.
+- _Dependency_ — Gatsby automatically tracks dependencies between different objects e.g. a page can depend on certain nodes. This allows for hot reloading, caching, incremental rebuilds, etc.
 - _Node_ — a data object
 - _Node Field_ — a field added by a plugin to a node that it doesn't control
-- _Node Link_ — a connection between nodes that gets converted to GraphQL
-  relationships. Can be created in a variety of ways as well as automatically
-  inferred. Parent/child links from nodes and their transformed derivative nodes
-  are first class links.
+- _Node Link_ — a connection between nodes that gets converted to GraphQL relationships. Can be created in a variety of ways as well as automatically inferred. Parent/child links from nodes and their transformed derivative nodes are first class links.
 
 _More definitions and terms are defined in the [Glossary](/docs/glossary/)_
 
@@ -88,36 +57,18 @@ _More definitions and terms are defined in the [Glossary](/docs/glossary/)_
 
 ### Extension APIs
 
-Gatsby has multiple processes. The most prominent is the "bootstrap" process. It
-has several subprocesses. One tricky part to their design is that they run both
-once during the initial bootstrap but also stay alive during development to
-continue to respond to changes. This is what drives hot reloading that all
-Gatsby data is "alive" and reacts to changes in the environment.
+Gatsby has multiple processes. The most prominent is the "bootstrap" process. It has several subprocesses. One tricky part to their design is that they run both once during the initial bootstrap but also stay alive during development to continue to respond to changes. This is what drives hot reloading that all Gatsby data is "alive" and reacts to changes in the environment.
 
 The bootstrap process is as follows:
 
-load site config -> load plugins -> source nodes -> transform nodes -> create
-graphql schema -> create pages -> compile component queries -> run queries ->
-fin
+load site config -> load plugins -> source nodes -> transform nodes -> create graphql schema -> create pages -> compile component queries -> run queries -> fin
 
 Once the initial bootstrap is finished, a `webpack-dev-server` and express server are started for serving files for the development workflow with live updates. For a production build, Gatsby skips the development server and instead builds the CSS, then JavaScript, then static HTML with webpack.
 
-During these processes there are various extension points where plugins can
-intervene. All major processes have an `onPre` and `onPost` e.g. `onPreBootstrap`
-and `onPostBootstrap` or `onPreBuild` or `onPostBuild`. During bootstrap,
-plugins can respond at various stages to APIs like `onCreatePages`,
-`onCreateBabelConfig`, and `onSourceNodes`.
-
-At each extension point, Gatsby identifies the plugins which implement the API
-and calls them in serial following their order in the site's `gatsby-config.js`.
-
-In addition to extension APIs in a node, plugins can also implement extension APIs
-in the server rendering process and the browser e.g. `onClientEntry` or
-`onRouteUpdate`
-
-The three main inspirations for this API and spec are React.js' API specifically
-[@leebyron's email on the React API](https://gist.github.com/vjeux/f2b015d230cc1ab18ed1df30550495ed),
-this talk
-["How to Design a Good API and Why it Matters" by Joshua Bloch](https://www.youtube.com/watch?v=heh4OeB9A-c&app=desktop)
-who designed many parts of Java, and [Hapi.js](https://hapijs.com/api)' plugin
-design.
+During these processes there are various extension points where plugins can intervene. All major processes have an `onPre` and `onPost` e.g. `onPreBootstrap` and `onPostBootstrap` or `onPreBuild` or `onPostBuild`. During bootstrap plugins can respond at various stages to APIs like `onCreatePages`, `onCreateBabelConfig`, and `onSourceNodes`.
+
+At each extension point, Gatsby identifies the plugins which implement the API and calls them in serial following their order in the site's `gatsby-config.js`.
+
+In addition to extension APIs in a node, plugins can also implement extension APIs in the server rendering process and the browser e.g. `onClientEntry` or `onRouteUpdate`.
+
+The three main inspirations for this API and spec are React.js' API specifically [@leebyron's email on the React API](https://gist.github.com/vjeux/f2b015d230cc1ab18ed1df30550495ed), this talk ["How to Design a Good API and Why it Matters" by Joshua Bloch](https://www.youtube.com/watch?v=heh4OeB9A-c&app=desktop) who designed many parts of Java, and [Hapi.js](https://hapijs.com/api)' plugin design.

docs/docs/babel-plugin-macros.md

@@ -2,34 +2,24 @@
 title: Using Babel Plugin Macros
 ---
 
-Gatsby includes a powerful new way of applying compile-time code
-transformations,
-[Babel macros](https://github.com/kentcdodds/babel-plugin-macros)! Macros are
-like Babel plugins, but instead of adding them to your `.babelrc`, you import them in
-the file you want to use them. This has two big advantages:
-
-- No confusion about where a non-standard syntax is coming from. Macros are
-  explicitly imported wherever they are used.
+Gatsby includes a powerful new way of applying compile-time code transformations, [Babel macros](https://github.com/kentcdodds/babel-plugin-macros)! Macros are like Babel plugins, but instead of adding them to your `.babelrc`, you import them in the file you want to use them. This has two big advantages:
+
+- No confusion about where a non-standard syntax is coming from. Macros are explicitly imported wherever they are used.
 - No configuration files. Macros are included directly in your code as needed.
 
-Like Babel plugins, macros run only at compile time. They are not included in
-the public JavaScript bundle. As such, macros have no effect on your code
-beyond the transformations they apply.
+Like Babel plugins, macros run only at compile time. They are not included in the public JavaScript bundle. As such, macros have no effect on your code beyond the transformations they apply.
 
 ## Installing macros
 
-Just like plugins, many macros are published as npm packages. By convention,
-they are named by their function, followed by `.macro`.
+Just like plugins, many macros are published as npm packages. By convention, they are named by their function, followed by `.macro`.
 
-For example, [`preval.macro`](https://www.npmjs.com/package/preval.macro) is a
-macro that pre-evaluates JavaScript code. You can install it by running:
+For example, [`preval.macro`](https://www.npmjs.com/package/preval.macro) is a macro that pre-evaluates JavaScript code. You can install it by running:
 
 ```shell
 npm install --save-dev preval.macro
 ```
 
-Some macros are instead included in larger packages. To install and use them,
-refer to their documentation.
+Some macros are instead included in larger packages. To install and use them, refer to their documentation.
 
 ## Using macros
 
@@ -55,7 +45,4 @@ const x = 1
 
 ## Discovering available macros
 
-Take a look at the
-[Awesome babel macros](https://github.com/jgierer12/awesome-babel-macros)
-list to find available macros you can use. Additionally, this list contains
-helpful resources for using macros and developing them yourself.
+Take a look at the [Awesome babel macros](https://github.com/jgierer12/awesome-babel-macros) list to find available macros you can use. Additionally, this list contains helpful resources for using macros and developing them yourself.

docs/docs/babel.md

@@ -2,29 +2,19 @@
 title: Babel
 ---
 
-Gatsby uses the phenomenal project [Babel](https://babeljs.io/) to enable
-support for writing modern JavaScript — while still supporting older browsers.
+Gatsby uses the phenomenal project [Babel](https://babeljs.io/) to enable support for writing modern JavaScript — while still supporting older browsers.
 
 ## How to specify which browsers to support
 
-Gatsby supports by default the last two versions of major browsers, IE 9+, as well as
-any browser that still has 1%+ browser share.
+Gatsby supports by default the last two versions of major browsers, IE 9+, as well as any browser that still has 1%+ browser share.
 
-This means that your JavaScript is automatically compiled to ensure it works on older browsers.
-Polyfills are also automatically added — no more shipping code which mysteriously
-breaks on older browsers!
+This means that your JavaScript is automatically compiled to ensure it works on older browsers. Polyfills are also automatically added — no more shipping code which mysteriously breaks on older browsers!
 
-If you only target newer browsers, see the [Browser
-Support](/docs/browser-support/) docs page for how to instruct Gatsby on which
-browsers you support and then Babel will start compiling for only these
-browsers.
+If you only target newer browsers, see the [Browser Support](/docs/browser-support/) docs page for how to instruct Gatsby on which browsers you support and then Babel will start compiling for only these browsers.
 
 ## How to use a custom .babelrc file
 
-Gatsby ships with a default .babelrc setup that should work for most sites. If you'd like
-to add custom Babel presets or plugins, you can create your own `.babelrc` at the root of
-your site, import [`babel-preset-gatsby`](https://github.com/gatsbyjs/gatsby/tree/master/packages/babel-preset-gatsby),
-and add additional plugins, presets, and pass options to `babel-preset-gatsby`, e.g. `targets`.
+Gatsby ships with a default .babelrc setup that should work for most sites. If you'd like to add custom Babel presets or plugins, you can create your own `.babelrc` at the root of your site, import [`babel-preset-gatsby`](https://github.com/gatsbyjs/gatsby/tree/master/packages/babel-preset-gatsby), and add additional plugins, presets, and pass options to `babel-preset-gatsby`, e.g. `targets`.
 
 ```shell
 npm install --save-dev babel-preset-gatsby

docs/docs/best-practices-for-orgs.md

@@ -11,5 +11,4 @@ When you have multiple teams building Gatsby sites, there are some best practice
 
 This is a stub. Help our community expand it.
 
-Please use the [Gatsby Style Guide](/contributing/gatsby-style-guide/) to ensure your
-pull request gets accepted.
+Please use the [Gatsby Style Guide](/contributing/gatsby-style-guide/) to ensure your pull request gets accepted.