Documentation Updates (#63)

* docs: add markdown linting

* docs: markdown cleanup

* docs: remove logoto prop

* docs: correct package doc generation

* docs: remove test post

.markdownlint.json

@@ -0,0 +1,20 @@
+{
+	"MD033": {
+		"allowed_elements": [
+			"author-details",
+			"view-source",
+			"img",
+			"text-tester",
+			"symbol-tester-width",
+			"symbol-tester-area",
+			"rule-tester",
+			"rect-tester",
+			"path-tester",
+			"line-tester",
+			"group-tester",
+			"area-tester-vertical",
+			"area-tester-horizontal",
+			"arc-tester"
+		]
+	}
+}

.vscode/launch.json

@@ -1,22 +1,44 @@
 {
-    // Use IntelliSense to learn about possible attributes.
-    // Hover to view descriptions of existing attributes.
-    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
-    "version": "0.2.0",
-    "configurations": [
-        {
-            "type": "chrome",
-            "request": "attach",
-            "name": "Attach to Chrome",
-            "port": 9222,
-            "webRoot": "${workspaceFolder}"
-        },
-        {
-            "type": "chrome",
-            "request": "launch",
-            "name": "Launch Chrome against localhost",
-            "url": "http://localhost:6006",
-            "webRoot": "${workspaceFolder}"
-        }
-    ]
-}
+	// Use IntelliSense to learn about possible attributes.
+	// Hover to view descriptions of existing attributes.
+	// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
+	"version": "0.2.0",
+	"configurations": [
+		{
+			"type": "chrome",
+			"request": "attach",
+			"name": "Attach to Chrome",
+			"port": 9222,
+			"webRoot": "${workspaceFolder}"
+		},
+		{
+			"type": "chrome",
+			"request": "launch",
+			"name": "Launch Chrome against localhost",
+			"url": "http://localhost:6006",
+			"webRoot": "${workspaceFolder}"
+		},
+		{
+			"name": "Gatsby develop",
+			"type": "node",
+			"request": "launch",
+			"protocol": "inspector",
+			"program": "${workspaceRoot}/packages/docs/docsite/node_modules/gatsby/dist/bin/gatsby",
+			"args": ["develop"],
+			"stopOnEntry": false,
+			"runtimeArgs": ["--nolazy"],
+			"sourceMaps": false
+		},
+		{
+			"name": "Gatsby build",
+			"type": "node",
+			"request": "launch",
+			"protocol": "inspector",
+			"program": "${workspaceRoot}/packages/docs/docsite/node_modules/gatsby/dist/bin/gatsby",
+			"args": ["build"],
+			"stopOnEntry": false,
+			"runtimeArgs": ["--nolazy"],
+			"sourceMaps": false
+		}
+	]
+}

package.json

@@ -8,7 +8,9 @@
 		"start:packages": "lerna run start --parallel --stream",
 		"test:packages": "lerna run test --stream",
 		"release:packages": "lerna run release --stream",
-		"lint": "eslint . --ext .js,.ts,.jsx,.tsx",
+		"lint:js": "eslint . --ext .js,.ts,.jsx,.tsx",
+		"lint:md": "markdownlint 'packages/docs/docsite/content/markdown/**/*.md'",
+		"lint": "run-s lint:*",
 		"unit_test": "jest --coverage --ci",
 		"test": "run-s lint build unit_test test:packages",
 		"publish_libs": "lerna publish",
@@ -44,6 +46,7 @@
 		"jest": "^24.9.0",
 		"jest-html": "^1.5.0",
 		"lerna": "^3.16.4",
+		"markdownlint-cli": "^0.18.0",
 		"npm-run-all": "^4.1.5",
 		"prettier": "^1.18.2",
 		"pretty-quick": "^1.11.1",

packages/docs/docsite/content/markdown/documentation/00_introduction.md

@@ -1,17 +1,29 @@
 ---
-title: 'Introduction'
-path: '/documentation/introduction'
+title: Introduction
+path: /documentation/introduction
 order: 0
 ---
 
-# Introduction
+## Introduction
 
-_chart-parts_ is a flexible [Grammar-of-Graphics](https://www.springer.com/us/book/9780387245447) rendering pipeline designed for application developers.
+_chart-parts_ is a flexible
+[Grammar-of-Graphics](https://www.springer.com/us/book/9780387245447)
+rendering pipeline designed for application developers.
 
-## Project Vision
+### Project Vision
 
-In his seminal book _The Grammar of Graphics_, Leland Wilkinson envisioned a system of charting components and data-flows to support charts. There have been several systems that have implemented these ideas, such as [Vega](http://vega.github.io/), [Vega-Lite](https://vega.github.io/vega-lite/) and [Altair](https://altair-viz.github.io/).
+In his seminal book _The Grammar of Graphics_, Leland Wilkinson envisioned a
+system of charting components and data-flows to support charts. There have been
+several systems that have implemented these ideas, such as
+[Vega](http://vega.github.io/), [Vega-Lite](https://vega.github.io/vega-lite/)
+and [Altair](https://altair-viz.github.io/).
 
 ![Wilkinson's Book](/images/wilkinson_book.png)
 
-The vision of `chart-parts` is to support the _rendering phases_ of Wilkinson's pipeline in a flexible, architecture-agnostic way while dovetailing nicely with React. To date, implementations of the _Grammar of Graphics_ have tended to exist as closed systems. While a closed system can be useful for certain users, and for certain abstraction levels, we believe that a closed graphical system should be built on top of an open graphics system to allow for maximum architectural flexibility.
+The vision of `chart-parts` is to support the _rendering phases_ of
+Wilkinson's pipeline in a flexible, architecture-agnostic way while
+dovetailing nicely with React. To date, implementations of the
+_Grammar of Graphics_ have tended to exist as closed systems. While a closed
+system can be useful for certain users, and for certain abstraction levels, we
+believe that a closed graphical system should be built on top of an open
+graphics system to allow for maximum architectural flexibility.

packages/docs/docsite/content/markdown/documentation/00_introduction_architecture.md

@@ -1,31 +1,53 @@
 ---
-title: 'Architecture'
-path: '/documentation/introduction/architecture'
+title: Architecture
+path: /documentation/introduction/architecture
 order: 2
 ---
 
 ## Architecture
 
-Creating charts is a process similar to compiling executable programs from source code. In a compilation process, there are two distinct phases "frontend compilation" and "backend compilation". These compilation phases use a generic representation known as an _Abstract Syntax Tree_ (AST) to communicate the structural representation of the source code. The frontend turns source code into this abstract representation, and the backend turns this abstract representation into executable software.
-
-The charting process is very similar. In charting, our notion of an AST comes from the [Vega Scenegraph](https://github.com/vega/vega-scenegraph). Vega's scenegraph is a plain Javascript object that is the result of binding a charting specification to user data. The scenegraph is then handled by rendering components to emit charts for users. We believe that the scenegraph specification is a useful abstraction that should allow any number of front-ends or back-ends to interact with, much like how modern compilers work.
+Creating charts is a process similar to compiling executable programs from
+source code. In a compilation process, there are two distinct phases "frontend
+compilation" and "backend compilation". These compilation phases use a generic
+representation known as an _Abstract Syntax Tree_ (AST) to communicate the
+structural representation of the source code. The frontend turns source code
+into this abstract representation, and the backend turns this abstract
+representation into executable software.
+
+The charting process is very similar. In charting, our notion of an AST comes
+from the [Vega Scenegraph](https://github.com/vega/vega-scenegraph). Vega's
+scenegraph is a plain Javascript object that is the result of binding a
+charting specification to user data. The scenegraph is then handled by
+rendering components to emit charts for users. We believe that the scenegraph
+specification is a useful abstraction that should allow any number of
+front-ends or back-ends to interact with, much like how modern compilers work.
 
 ### Architecture Diagram
 
 ![Architecture Pipeline Diagram](/images/architecture_pipeline.png)
 
 ### Frontend Charting Components
 
-The front-end of our charting system is comprised of everything required to turn data into a Scenegraph. The frontend consists primarily of:
+The front-end of our charting system is comprised of everything required to
+turn data into a Scenegraph. The frontend consists primarily of:
 
 - A _SceneBuilder_ API that is used to create scene specifications.
-- A _React Renderless_ component set that is used as a convenience for the SceneNodeBuilder API.
-- A _Scene Generator_ that binds a scene specification to user data and emits Scenegraph objects.
+- A _React Renderless_ component set that is used as a convenience for the
+  SceneNodeBuilder API.
+- A _Scene Generator_ that binds a scene specification to user data and emits
+  Scenegraph objects.
 
 ### Backend Charting Components
 
-The goal of the backend charting components is to translate the Scenegraph object into an output that is viewable by users. Our goal is to support several rendering options, from dom-based SVG to more advanced WebGL rendering.
+The goal of the backend charting components is to translate the Scenegraph
+object into an output that is viewable by users. Our goal is to support
+several rendering options, from dom-based SVG to more advanced WebGL rendering.
 
 #### SVG Renderers
 
-We support (or plan to support) of number of SVG-based output rendering options. Currently there is support for rendering SVG in **React-DOM** and **React-Native-SVG**. SVG-based renderers operate by first translating the scenegraph into a _Virtual SVG_, which is a virtual-dom of SVG-based nodes. This is then translated into any svg-based output. Our react-based outputs emit React virtual-dom based on whatever SVG elements are appropriate for the platform.
+We support (or plan to support) of number of SVG-based output rendering
+options. Currently there is support for rendering SVG in **React-DOM** and
+**React-Native-SVG**. SVG-based renderers operate by first translating the
+scenegraph into a _Virtual SVG_, which is a virtual-dom of SVG-based nodes.
+This is then translated into any svg-based output. Our react-based outputs emit
+React virtual-dom based on whatever SVG elements are appropriate for the platform.

packages/docs/docsite/content/markdown/documentation/00_introduction_background.md

@@ -1,22 +1,38 @@
 ---
-title: 'History & Related Work'
-path: '/documentation/introduction/background'
+title: History & Related Work
+path: /documentation/introduction/background
 order: 1
 ---
 
 ## Mark-Based Visualization Systems
 
-Mark-based visualization systems implement a concept known as the _Grammar of Graphics_. These systems are built on the analogy that graphical elements are to charting as words are to prose, and they are constructed of a "language" of fundamental charting elements. These charting elements are described at a higher level than raw graphics primitives.
+Mark-based visualization systems implement a concept known as the
+_Grammar of Graphics_. These systems are built on the analogy that graphical
+elements are to charting as words are to prose, and they are constructed of a
+"language" of fundamental charting elements. These charting elements are
+described at a higher level than raw graphics primitives.
 
-In _The Grammar of Graphics_, Leland Wilkinson envisions a sequenced pipeline of steps that are common to creating charts: including data transformations, scale applications, mark binding, and rendering of marks and guides. 
+In _The Grammar of Graphics_, Leland Wilkinson envisions a sequenced pipeline
+of steps that are common to creating charts: including data transformations,
+scale applications, mark binding, and rendering of marks and guides.
 
 ![Leland Wilkinson's Grammar of Graphics Pipeline](/images/pipeline.png)
 
-### Vega 
-Mark-based systems are common in data-visualization research, but are relatively rare in practice. The most notable implementations of these systems presently are [Vega](http://vega.github.io/) and systems based on Vega such as [Vega-Lite](https://vega.github.io/vega-lite/) and [Altair](https://altair-viz.github.io/).
+### Vega
 
-Vega's mark-based abstraction is excellent, but there are some design issues with its API that make it suboptimal for integrating into applications:
+Mark-based systems are common in data-visualization research, but are
+relatively rare in practice. The most notable implementations of these systems
+presently are [Vega](http://vega.github.io/) and systems based on Vega such as
+[Vega-Lite](https://vega.github.io/vega-lite/)
+and [Altair](https://altair-viz.github.io/).
 
-- The pure-declarative nature of the JSON-specifications can be cumbersome to work with.
-- The signal/state system of Vega allows for the observation and mutation of chart state, but application developers often want to control their own state and have control over what happens with events.
-- The rendering engine is browser-dependent, precluding it from being used in native contexts.
+Vega's mark-based abstraction is excellent, but there are some design issues
+with its API that make it suboptimal for integrating into applications:
+
+- The pure-declarative nature of the JSON-specifications can be cumbersome to
+  work with.
+- The signal/state system of Vega allows for the observation and mutation of
+  chart state, but application developers often want to control their own state
+  and have control over what happens with events.
+- The rendering engine is browser-dependent, precluding it from being used in
+  native contexts.

packages/docs/docsite/content/markdown/documentation/00_introduction_problem.md

@@ -1,13 +1,25 @@
 ---
-title: 'The Missing Abstraction'
-path: '/documentation/introduction/missing_abstraction'
+title: The Missing Abstraction
+path: /documentation/introduction/missing_abstraction
 order: 0
 ---
 
 ## The Missing Abstraction of Charting
 
-Charting is a common and complex problem. Charting libraries are often implemented with the most common visualizations and use-cases in mind. When a developer wants to augment a chart or make something slightly out-of-the-box, such as a mean line in a bar chart, it's often necessary to eject out of the charting library and work directly with a 2D rendering API such as _svg_, _canvas_ or _webgl_. Additionally, charting libraries are often browser-dependent, which precludes the ability to abstractly describe charts independently of platform.
+Charting is a common and complex problem. Charting libraries are often
+implemented with the most common visualizations and use-cases in mind. When a
+developer wants to augment a chart or make something slightly out-of-the-box,
+such as a mean line in a bar chart, it's often necessary to eject out of the
+charting library and work directly with a 2D rendering API such as _svg_,
+_canvas_ or _webgl_. Additionally, charting libraries are often
+browser-dependent, which precludes the ability to abstractly describe charts
+independently of platform.
 
 ![The missing abstraction of charting](/images/missing_abstraction.png)
 
-We believe that the notion of a _Grammar of Graphics_, sometimes referred to as _mark-based visualization_, has been proved in many contexts to be an elegant way to describe expressive, beautiful charts that are not as constrained by the charting library that is selected. Moreover, this level of abstraction is easier to develop software at than low-level graphics libraries, and is not bound a-priori to any platform.
+We believe that the notion of a _Grammar of Graphics_, sometimes referred to as
+_mark-based visualization_, has been proved in many contexts to be an elegant
+way to describe expressive, beautiful charts that are not as constrained by
+the charting library that is selected. Moreover, this level of abstraction is
+easier to develop software at than low-level graphics libraries, and is not
+bound a-priori to any platform.

packages/docs/docsite/content/markdown/documentation/01_concepts.md

@@ -1,14 +1,17 @@
 ---
-title: 'Concepts'
-path: '/documentation/concepts'
+title: Concepts
+path: /documentation/concepts
 order: 1
 ---
 
 ## Key Concepts
 
-In this section we will describe, at overview-level, the key concepts that are used to create charts using chart-parts. These concepts will likely be familiar to people with a background in data-visulization, especially if they have used mark-based visulization systems before.
+In this section we will describe, at overview-level, the key concepts that are
+used to create charts using chart-parts. These concepts will likely be familiar
+to people with a background in data-visulization, especially if they have used
+mark-based visulization systems before.
 
-* [Scales](/documentation/concepts/scales)
-* [Marks](/documentation/concepts/marks)
-* [Axes](/documentation/concepts/axes)
-* [View Nesting](/documentation/concepts/view_nesting)
+- [Scales](/documentation/concepts/scales)
+- [Marks](/documentation/concepts/marks)
+- [Axes](/documentation/concepts/axes)
+- [View Nesting](/documentation/concepts/view_nesting)

packages/docs/docsite/content/markdown/documentation/01_concepts_axes.md

@@ -1,13 +1,18 @@
 ---
-title: 'Axes'
-path: '/documentation/concepts/axes'
+title: Axes
+path: /documentation/concepts/axes
 order: 2
 ---
 
 ## Axes
 
 ![Bar Chart](/images/barchart.png)
 
-Axes are a common feature of charts where we can understand the encoding of a dimension in the view-space. Our system provides the ability to create Axes with a chart orientation (Top, Bottom, Left, Right) that are bound to a scale. For more information on creating scales, see the [Client API](/documentation/apis) section.
+Axes are a common feature of charts where we can understand the encoding of a
+dimension in the view-space. Our system provides the ability to create Axes
+with a chart orientation (Top, Bottom, Left, Right) that are bound to a scale.
+For more information on creating scales, see the
+[Client API](/documentation/apis) section.
 
-Axes can be constructed with a variety of options, including tick and label parameterization.
+Axes can be constructed with a variety of options, including tick and label
+parameterization.