fix: add formatting rules for Prettier (#347)

Author: tomarra

.github/ISSUE_TEMPLATE/chore.md

@@ -7,7 +7,8 @@ labels: chore
 
 **Description**
 
-Clearly describe what change is needed and why. If this changes code then please use another issue type.
+Clearly describe what change is needed and why. If this changes code then please
+use another issue type.
 
 **Requirements**
 

.github/ISSUE_TEMPLATE/documentation.md

@@ -1,6 +1,7 @@
 ---
 name: Documentation
-about: Improve the documentation so all collaborators have a common understanding
+about:
+  Improve the documentation so all collaborators have a common understanding
 title: 'docs: '
 labels: documentation
 ---

.github/ISSUE_TEMPLATE/performance.md

@@ -7,7 +7,8 @@ labels: performance
 
 **Description**
 
-Clearly describe what code needs to be changed and what the performance impact is going to be. Bonus point's if you can tie this directly to user experience.
+Clearly describe what code needs to be changed and what the performance impact
+is going to be. Bonus point's if you can tie this directly to user experience.
 
 **Requirements**
 

.github/ISSUE_TEMPLATE/refactor.md

@@ -7,7 +7,8 @@ labels: refactor
 
 **Description**
 
-Clearly describe what needs to be refactored and why. Please provide links to related issues (bugs or upcoming features) in order to help prioritize.
+Clearly describe what needs to be refactored and why. Please provide links to
+related issues (bugs or upcoming features) in order to help prioritize.
 
 **Requirements**
 

.github/ISSUE_TEMPLATE/style.md

@@ -1,6 +1,8 @@
 ---
 name: Style Changes
-about: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+about:
+  Changes that do not affect the meaning of the code (white-space, formatting,
+  missing semi-colons, etc)
 title: 'style: '
 labels: style
 ---

.github/ISSUE_TEMPLATE/test.md

@@ -7,7 +7,8 @@ labels: test
 
 **Description**
 
-List out the tests that need to be added or changed. Please also include any information as to why this was not covered in the past.
+List out the tests that need to be added or changed. Please also include any
+information as to why this was not covered in the past.
 
 **Requirements**
 

.prettierrc

@@ -1,3 +1,5 @@
 {
-  "singleQuote": true
+  "singleQuote": true,
+  "printWidth": 80,
+  "proseWrap": "always"
 }

README.md

@@ -19,4 +19,6 @@ All commands are run from the root of the project, from a terminal:
 
 ## 👀 Want to learn more?
 
-Check out [Starlight’s docs](https://starlight.astro.build/), read [the Astro documentation](https://docs.astro.build), or jump into the [Astro Discord server](https://astro.build/chat).
+Check out [Starlight’s docs](https://starlight.astro.build/), read
+[the Astro documentation](https://docs.astro.build), or jump into the
+[Astro Discord server](https://astro.build/chat).

package-lock.json

@@ -13,44 +13,44 @@ overview of the components that make up the Shorebird system.
 
 ## Lifetime of a Shorebird Update
 
-This assumes the developer already has installed Shorebird and has a working Flutter
-project, as covered in the [Getting Started](/) guide.
+This assumes the developer already has installed Shorebird and has a working
+Flutter project, as covered in the [Getting Started](/) guide.
 
 `shorebird init` tells Shorebird servers to create a new "App" entry associated
 with your account as well as writes the resulting app_id to `shorebird.yaml` in
 your project.
 
-`shorebird release` builds your app using `flutter build` and then uploads
-the resulting binary to a private Google Cloud Storage bucket. The command
-also creates a "release" record in our database that associates the app_id
-with the release version.
+`shorebird release` builds your app using `flutter build` and then uploads the
+resulting binary to a private Google Cloud Storage bucket. The command also
+creates a "release" record in our database that associates the app_id with the
+release version.
 
 `shorebird preview` can be used to download and run any of these privately
 stored release binaries on your local device.
 
-Developers then typically take the resulting .aab or .ipa and distribute it
-to their users, typically via the Play Store or App Store.
+Developers then typically take the resulting .aab or .ipa and distribute it to
+their users, typically via the Play Store or App Store.
 
-At some point later, developers use `shorebird patch` to build a new version
-of their app. `shorebird patch` then downloads the previous release binary
+At some point later, developers use `shorebird patch` to build a new version of
+their app. `shorebird patch` then downloads the previous release binary
 associated with that app_id and version number (patches use the same version
-number as the release they are patching) and then builds a "patch diff" from
-the combined release and patch binaries. This "patch diff" is then uploaded
-to a public Google Cloud Storage bucket where it will be served to devices
-requesting an update with the corresponding app_id and release version.
+number as the release they are patching) and then builds a "patch diff" from the
+combined release and patch binaries. This "patch diff" is then uploaded to a
+public Google Cloud Storage bucket where it will be served to devices requesting
+an update with the corresponding app_id and release version.
 
 `shorebird patch` also creates a record in our database that associates the
 patch with the app_id and release version and alerts our "patch check" servers
-that a new patch is available. Patches can optionally be "staged" when
-uploaded. They will then not appear in patch checks until the patch "channel"
-is set to "stable" by the developer in the Shorebird Console.
+that a new patch is available. Patches can optionally be "staged" when uploaded.
+They will then not appear in patch checks until the patch "channel" is set to
+"stable" by the developer in the Shorebird Console.
 
 Release binaries which were built with Shorebird contain Shorebird's updater
-library. By default, the updater library will check for patches every time
-the app is started. This is done via a background thread to not slow down
-launch. The updater code makes a single request to our "patch check" servers
-which are again Google Cloud Run instances. The "patch check" servers
-respond with the URL of the patch diff if one is available.
+library. By default, the updater library will check for patches every time the
+app is started. This is done via a background thread to not slow down launch.
+The updater code makes a single request to our "patch check" servers which are
+again Google Cloud Run instances. The "patch check" servers respond with the URL
+of the patch diff if one is available.
 
 A typical patch check is made via https, and contains:
 
@@ -78,24 +78,24 @@ A patch response contains:
 }
 ```
 
-The code to do these checks is open source as part of the [Shorebird Updater
-library](https://github.com/shorebirdtech/updater/blob/main/library) and may
-change from what is documented above:
+The code to do these checks is open source as part of the
+[Shorebird Updater library](https://github.com/shorebirdtech/updater/blob/main/library)
+and may change from what is documented above:
 https://github.com/shorebirdtech/updater/blob/main/library/src/network.rs
 
-The updater library then downloads the patch diff and applies it to the
-release binary. The patch diff is a binary diff. The updater library
-also checks the hash of the patch diff to confirm download integrity.
+The updater library then downloads the patch diff and applies it to the release
+binary. The patch diff is a binary diff. The updater library also checks the
+hash of the patch diff to confirm download integrity.
 
 The hash is not meant to be a security feature, but rather a way to detect
-errors in the patch diff. A common error we see is that developers `shorebird
-release` with one source and then actually build and release a different binary,
-resulting then in invalid patches. This hash helps detect such errors. We
-currently do not sign patches, but plan to add that capability in the near
-future.
+errors in the patch diff. A common error we see is that developers
+`shorebird release` with one source and then actually build and release a
+different binary, resulting then in invalid patches. This hash helps detect such
+errors. We currently do not sign patches, but plan to add that capability in the
+near future.
 
-The modified Flutter engine also reports successful or failed launch of
-a patch back to our servers the next time it makes a patch check.
+The modified Flutter engine also reports successful or failed launch of a patch
+back to our servers the next time it makes a patch check.
 
 A patch event contains:
 
@@ -122,13 +122,15 @@ This is to prevent a bad patch from causing a crash loop on the device.
 
 Shorebird consists of 3 major parts:
 
-1. The `Shorebird CLI` tool that you use to build and deploy your app from the command line.
+1. The `Shorebird CLI` tool that you use to build and deploy your app from the
+   command line.
 1. A modified Flutter engine that is include in your app.
 1. Our public-cloud infrastructure which hosts your app's updates.
 
 ### The `Shorebird CLI`
 
-The [`shorebird_cli`](https://github.com/shorebirdtech/shorebird/tree/main/packages/shorebird_cli)
+The
+[`shorebird_cli`](https://github.com/shorebirdtech/shorebird/tree/main/packages/shorebird_cli)
 commands are documented on this site. Most of the build logic is just wrapping
 the `flutter` tool and it also adds a few commands to interface with Shorebird's
 servers.
@@ -142,18 +144,19 @@ We had to fork 4 Flutter and Dart repositories to make Shorebird work:
 
 #### `flutter/buildroot` "The Buildroot"
 
-The [`flutter/buildroot`](https://github.com/flutter/buildroot) repo contains the build scripts that are used to build the
-Flutter engine for various platforms. It's separate from `flutter/engine` in
-order to share code and configuration with the Fuchsia build system.
+The [`flutter/buildroot`](https://github.com/flutter/buildroot) repo contains
+the build scripts that are used to build the Flutter engine for various
+platforms. It's separate from `flutter/engine` in order to share code and
+configuration with the Fuchsia build system.
 
 We forked this repository to make several small modifications:
 
 1. Expose our updater symbols from the Flutter engine up to
    `package:shorebird_code_push`
 
-1. Include `libunwind` since the [Shorebird
-   Updater](https://github.com/shorebirdtech/updater) (Rust) code requires it
-   for backtraces.
+1. Include `libunwind` since the
+   [Shorebird Updater](https://github.com/shorebirdtech/updater) (Rust) code
+   requires it for backtraces.
 
 The [Shorebird Updater](https://github.com/shorebirdtech/updater) is a Rust
 library which is linked into the Flutter engine via a static library
@@ -164,9 +167,8 @@ static libraries, and because we need to be able to expose the `shorebird\_\*`
 symbols from `libupdater.a` to the Dart code, we made one change to `buildroot`
 and then a second change to the `engine` to place the symbols on the allow-list.
 
-:::note
-You can see our buildroot changes on GitHub by
-comparing our trunk to the upstream buildroot, e.g. master:
+:::note You can see our buildroot changes on GitHub by comparing our trunk to
+the upstream buildroot, e.g. master:
 https://github.com/flutter/buildroot/compare/master...shorebirdtech:buildroot:shorebird/dev
 :::
 
@@ -180,24 +182,24 @@ We forked this code to add the
 [Shorebird Updater](https://github.com/shorebirdtech/updater), which lets the
 Flutter engine load new code from Shorebird's servers.
 
-:::note
-Our Flutter Engine fork is public. You can see our engine changes on GitHub by
-comparing our trunk to the upstream Flutter engine, e.g. for 3.22.0:
+:::note Our Flutter Engine fork is public. You can see our engine changes on
+GitHub by comparing our trunk to the upstream Flutter engine, e.g. for 3.22.0:
 https://github.com/flutter/engine/compare/3.22.0...shorebirdtech:engine:shorebird/dev
 :::
 
 #### `flutter/flutter` "The Flutter Framework"
 
-The [`flutter/flutter`](https://github.com/flutter/flutter/) repo contains the Dart code that runs on the device as well
-as the `flutter` tool that is used to build and run Flutter apps.
+The [`flutter/flutter`](https://github.com/flutter/flutter/) repo contains the
+Dart code that runs on the device as well as the `flutter` tool that is used to
+build and run Flutter apps.
 
 We forked this code to be able to deliver our modified Flutter engine to change
 the version of the engine that the `flutter` tool uses and to include the
 `shorebird.yaml` configuration as part of the asset bundle.
 
-:::note
-Our Flutter Framework fork is public. You can see our engine changes on GitHub
-by comparing our trunk to the upstream Flutter Framework, e.g. for stable:
+:::note Our Flutter Framework fork is public. You can see our engine changes on
+GitHub by comparing our trunk to the upstream Flutter Framework, e.g. for
+stable:
 https://github.com/flutter/flutter/compare/stable...shorebirdtech:flutter:shorebird/dev
 :::
 
@@ -209,11 +211,9 @@ SDK, including the VM, dart2js, core libraries, and more.
 We forked this code in order to teach Dart how to run modified (patched) code in
 an interpreter while being able to run all unmodified code on the CPU.
 
-:::note
-Our Dart SDK fork is private currently. It will likely be public in the future
-and we will work to upstream many our changes as the team grows and the product
-matures.
-:::
+:::note Our Dart SDK fork is private currently. It will likely be public in the
+future and we will work to upstream many our changes as the team grows and the
+product matures. :::
 
 #### Installing a Forked Flutter
 
@@ -232,18 +232,19 @@ change the version of the engine in the `flutter` tool. Second is we pass
 `FLUTTER_STORAGE_BASE_URL` set to `download.shorebird.dev` (instead of
 `download.flutter.io`) when calling our vended copy of the `flutter` tool.
 
-Currently this means `shorebird` will not work in an environment where the
-user needs to use `FLUTTER_STORAGE_BASE_URL` to download Flutter artifacts
-from a private mirror (e.g. a corporate network or China).
+Currently this means `shorebird` will not work in an environment where the user
+needs to use `FLUTTER_STORAGE_BASE_URL` to download Flutter artifacts from a
+private mirror (e.g. a corporate network or China).
 https://github.com/shorebirdtech/shorebird/issues/237
 
 #### Serving Forked Binaries
 
-We also use a custom server to handle requests from `flutter` for our
-modified engine. The source for that server is here:
+We also use a custom server to handle requests from `flutter` for our modified
+engine. The source for that server is here:
 https://github.com/shorebirdtech/shorebird/tree/main/packages/artifact_proxy
 
-The artifact proxy is hosted at https://download.shorebird.dev via Google Cloud Run.
+The artifact proxy is hosted at https://download.shorebird.dev via Google Cloud
+Run.
 
 This proxy knows how to serve the modified binaries from our Google Storage
 bucket, as well as how to forward along requests to Google's Flutter storage
@@ -259,9 +260,9 @@ app's updates. It's a set of services that handle the following:
 - Patch binary (public) storage and serving (via global CDN)
 - Patch check requests (via Google Cloud Run)
 
-We also provide a web-based console for developers to manage their apps and
-view analytics as well as the underlying database that powers the patch checks
-and console.
+We also provide a web-based console for developers to manage their apps and view
+analytics as well as the underlying database that powers the patch checks and
+console.
 
 Currently all of our infrastructure is hosted on Google Cloud Platform although
 we will likely expand to other cloud providers over time. If we do, we will