DOCS-685: Use prettier linter (#1835)

Author: npentrel

Diff for: .markdownlint.yaml

@@ -8,6 +8,9 @@ options:
 MD010:
   spaces_per_tab: 4
 
+MD007:
+  indent: 2
+
 # MD013/line-length - Line length
 MD013: false
 
@@ -25,3 +28,9 @@ MD041: false
 
 # Code block style expect indented
 MD046: false
+
+# Emphasis style
+MD049: "underscore"
+
+# Space after list marker - needed for prettier linter
+MD030: false

Diff for: .prettierrc

@@ -0,0 +1,4 @@
+{
+	"tabWidth": 2,
+	"proseWrap": "preserve"
+}

Diff for: docs/_index.md

@@ -10,6 +10,7 @@ hide_feedback: true
 sitemap:
   priority: 1.0
 ---
+
 <div class="max-page">
   <p>
     Welcome to the Viam Documentation!

Diff for: docs/appendix/_index.md

@@ -5,4 +5,4 @@ weight: 90
 simple_list: true
 type: "docs"
 description: "Reference and Background Material"
----
+---

Diff for: docs/appendix/contribute.md

@@ -6,6 +6,7 @@ draft: true
 type: "docs"
 description: "A guide to viewing and contributing to Viam's open source efforts."
 ---
+
 ## Coming soon
 
 This page will contain information on:

Diff for: docs/appendix/glossary/api-namespace-triplet.md

@@ -8,10 +8,10 @@ aka:
 
 Every Viam {{< glossary_tooltip term_id="resource" text="resource" >}} subtype exposes an [application programming interface (API)](https://en.wikipedia.org/wiki/API) to describe how you can interact with that resource.
 
- These APIs are organized by colon-delimited-triplet identifiers, in the form of `namespace:type:subtype`.
+These APIs are organized by colon-delimited-triplet identifiers, in the form of `namespace:type:subtype`.
 
- The `namespace` for built-in Viam resources is `rdk`, while the `type` is `component` or `service`.
- `subtype` refers to a specific component or service, like a `camera` or `vision`.
+The `namespace` for built-in Viam resources is `rdk`, while the `type` is `component` or `service`.
+`subtype` refers to a specific component or service, like a `camera` or `vision`.
 
 One subtype can have various models, custom or built-in, but they all must conform to the subtype's API definition.
 This requirement ensures that when a resource of that model is deployed, you can [interface with it](/program/) using the same [client API methods](/program/apis/) you would when programming resources of the same subtype with a different model.

Diff for: docs/appendix/glossary/attribute.md

@@ -7,4 +7,4 @@ aka:
 type: "page"
 ---
 
- A configuration parameter of a resource.
+A configuration parameter of a resource.

Diff for: docs/appendix/glossary/index.md

@@ -9,4 +9,4 @@ card:
   name: reference
   weight: 10
   title: Glossary
----
+---

Diff for: docs/appendix/glossary/model.md

@@ -8,4 +8,4 @@ aka:
 
 A particular implementation of a {{< glossary_tooltip term_id="resource" text="resource" >}} {{< glossary_tooltip term_id="subtype" text="subtype" >}}.
 
-For example: `ur5e` is a *model* of arm, implementing the [resource API](/program/apis/) of the [arm](/components/arm/) subtype of {{< glossary_tooltip term_id="component" text="component" >}}, which, in turn, is a {{< glossary_tooltip term_id="type" text="type" >}} of resource.
+For example: `ur5e` is a _model_ of arm, implementing the [resource API](/program/apis/) of the [arm](/components/arm/) subtype of {{< glossary_tooltip term_id="component" text="component" >}}, which, in turn, is a {{< glossary_tooltip term_id="type" text="type" >}} of resource.

Diff for: docs/appendix/glossary/part.md

@@ -6,6 +6,6 @@ short_description: A single-board computer, desktop, laptop, or other computer r
 aka:
 ---
 
-Robots are organized into *parts*, where each part represents a computer (a [single-board computer](/installation/), desktop, laptop, or other computer) running `viam-server`, the hardware {{< glossary_tooltip term_id="component" text="components" >}} attached to it, and any {{< glossary_tooltip term_id="service" text="services" >}} or other resources running on it.
+Robots are organized into _parts_, where each part represents a computer (a [single-board computer](/installation/), desktop, laptop, or other computer) running `viam-server`, the hardware {{< glossary_tooltip term_id="component" text="components" >}} attached to it, and any {{< glossary_tooltip term_id="service" text="services" >}} or other resources running on it.
 
 For more information, see [Robot Architecture: Parts, Sub-Parts and Remotes](/manage/parts-and-remotes/).

Diff for: docs/appendix/glossary/robot.md

@@ -6,6 +6,6 @@ short_description: An organizational concept, consisting of either one part, or
 aka:
 ---
 
-An organizational concept, consisting of either one *{{< glossary_tooltip term_id="part" text="part" >}}*, or multiple *parts* working closely together to complete tasks.
+An organizational concept, consisting of either one _{{< glossary_tooltip term_id="part" text="part" >}}_, or multiple _parts_ working closely together to complete tasks.
 
 For more information, see [Robots](../../manage/fleet/robots/).

Diff for: docs/appendix/glossary/type.md

@@ -2,11 +2,11 @@
 title: Type
 id: type
 full_link:
-short_description: Component and service are the built-in types of resource API the RDK provides. 
+short_description: Component and service are the built-in types of resource API the RDK provides.
 aka:
 ---
 
-In the {{< glossary_tooltip term_id="rdk" text="RDK" >}} architecture's {{< glossary_tooltip term_id="api-namespace-triplet" text="namespace triplet" >}} for resource APIs, *type* refers to the distinction between {{< glossary_tooltip term_id="component" text="component" >}} or {{< glossary_tooltip term_id="service" text="service" >}}.
+In the {{< glossary_tooltip term_id="rdk" text="RDK" >}} architecture's {{< glossary_tooltip term_id="api-namespace-triplet" text="namespace triplet" >}} for resource APIs, _type_ refers to the distinction between {{< glossary_tooltip term_id="component" text="component" >}} or {{< glossary_tooltip term_id="service" text="service" >}}.
 
 However, the meaning of "type" can be context dependent across the Viam platform.
 

Diff for: docs/appendix/glossary/viam-robot-api.md

@@ -13,4 +13,4 @@ The specification for communication with resources.
 
 Currently, the Viam Robot API is defined in a collection of Protocol Buffer files.
 
-All SDKs written by Viam use {{< glossary_tooltip term_id="grpc" text="gRPC" >}}  but the Viam Robot API itself does not mandate gRPC as the transport mechanism.
+All SDKs written by Viam use {{< glossary_tooltip term_id="grpc" text="gRPC" >}} but the Viam Robot API itself does not mandate gRPC as the transport mechanism.

Diff for: docs/appendix/learning-resources.md

@@ -5,6 +5,7 @@ description: "A collection of links to external sources discussing robotics topi
 type: "docs"
 draft: true
 ---
+
 ## Overview
 
 The following sections contain links that we think you will find useful during your journey into robotics.
@@ -68,7 +69,7 @@ And their values on a resistor:
 
 - The bands 1 and 2 indicate the first two significant digits on a resistor.
 - Band 3 is a multiplier on four-band resistors.
-For example, a resistor with brown, green, orange bands representing, 1, 5, and  3, respectively, which equates to 15 times ten to the third, or 15,000 Ohms, or 15 kOhms.
+  For example, a resistor with brown, green, orange bands representing, 1, 5, and 3, respectively, which equates to 15 times ten to the third, or 15,000 Ohms, or 15 kOhms.
 - On resistors with four bands, the band 4 indicates tolerance, with gold being +/- 5% and silver being +/- 10%.
 - On five-band resistors, band 3 becomes an additional significant digit, band 4 becomes the multiplier, and band 5 becomes the tolerance band.
 - Six-band resistors are read identically to five-band resistors, their difference being that the sixth band indicates the resistor's temperature coefficient.