Prettier

Signed-off-by: Michael Telatynski <[email protected]>

.github/PULL_REQUEST_TEMPLATE.md

@@ -2,7 +2,7 @@
 
 ## Checklist
 
--   [ ] Tests written for new code (and old code if feasible).
--   [ ] New or updated `public`/`exported` symbols have accurate [TSDoc](https://tsdoc.org/) documentation.
--   [ ] Linter and other CI checks pass.
--   [ ] I have licensed the changes to Element by completing the [Contributor License Agreement (CLA)](https://cla-assistant.io/element-hq/element-web)
+- [ ] Tests written for new code (and old code if feasible).
+- [ ] New or updated `public`/`exported` symbols have accurate [TSDoc](https://tsdoc.org/) documentation.
+- [ ] Linter and other CI checks pass.
+- [ ] I have licensed the changes to Element by completing the [Contributor License Agreement (CLA)](https://cla-assistant.io/element-hq/element-web)

CONTRIBUTING.md

@@ -20,26 +20,26 @@ Definitely don't use the GitHub default of "Update file.ts".
 
 As for your PR description, it should include these things:
 
--   References to any bugs fixed by the change (in GitHub's `Fixes` notation)
--   Describe the why and what is changing in the PR description so it's easy for
-    onlookers and reviewers to onboard and context switch. This information is
-    also helpful when we come back to look at this in 6 months and ask "why did
-    we do it like that?" we have a chance of finding out.
-    -   Why didn't it work before? Why does it work now? What use cases does it
-        unlock?
-    -   If you find yourself adding information on how the code works or why you
-        chose to do it the way you did, make sure this information is instead
-        written as comments in the code itself.
-    -   Sometimes a PR can change considerably as it is developed. In this case,
-        the description should be updated to reflect the most recent state of
-        the PR. (It can be helpful to retain the old content under a suitable
-        heading, for additional context.)
--   Include both **before** and **after** screenshots to easily compare and discuss
-    what's changing.
--   Include a step-by-step testing strategy so that a reviewer can check out the
-    code locally and easily get to the point of testing your change.
--   Add comments to the diff for the reviewer that might help them to understand
-    why the change is necessary or how they might better understand and review it.
+- References to any bugs fixed by the change (in GitHub's `Fixes` notation)
+- Describe the why and what is changing in the PR description so it's easy for
+  onlookers and reviewers to onboard and context switch. This information is
+  also helpful when we come back to look at this in 6 months and ask "why did
+  we do it like that?" we have a chance of finding out.
+    - Why didn't it work before? Why does it work now? What use cases does it
+      unlock?
+    - If you find yourself adding information on how the code works or why you
+      chose to do it the way you did, make sure this information is instead
+      written as comments in the code itself.
+    - Sometimes a PR can change considerably as it is developed. In this case,
+      the description should be updated to reflect the most recent state of
+      the PR. (It can be helpful to retain the old content under a suitable
+      heading, for additional context.)
+- Include both **before** and **after** screenshots to easily compare and discuss
+  what's changing.
+- Include a step-by-step testing strategy so that a reviewer can check out the
+  code locally and easily get to the point of testing your change.
+- Add comments to the diff for the reviewer that might help them to understand
+  why the change is necessary or how they might better understand and review it.
 
 ### Changelogs
 
@@ -79,8 +79,8 @@ element-web notes: Fix a bug where the 'Herd' button only worked on Tuesdays
 
 This example is for Element Web. You can specify:
 
--   element-web
--   element-desktop
+- element-web
+- element-desktop
 
 If your PR introduces a breaking change, use the `Notes` section in the same
 way, additionally adding the `X-Breaking-Change` label (see below). There's no need
@@ -96,10 +96,10 @@ Notes: Remove legacy `Camelopard` class. `Giraffe` should be used instead.
 
 Other metadata can be added using labels.
 
--   `X-Breaking-Change`: A breaking change - adding this label will mean the change causes a _major_ version bump.
--   `T-Enhancement`: A new feature - adding this label will mean the change causes a _minor_ version bump.
--   `T-Defect`: A bug fix (in either code or docs).
--   `T-Task`: No user-facing changes, eg. code comments, CI fixes, refactors or tests. Won't have a changelog entry unless you specify one.
+- `X-Breaking-Change`: A breaking change - adding this label will mean the change causes a _major_ version bump.
+- `T-Enhancement`: A new feature - adding this label will mean the change causes a _minor_ version bump.
+- `T-Defect`: A bug fix (in either code or docs).
+- `T-Task`: No user-facing changes, eg. code comments, CI fixes, refactors or tests. Won't have a changelog entry unless you specify one.
 
 If you don't have permission to add labels, your PR reviewer(s) can work with you
 to add them: ask in the PR description or comments.

README.md

@@ -16,28 +16,28 @@ JS SDK](https://github.com/matrix-org/matrix-js-sdk).
 
 Element has several tiers of support for different environments:
 
--   Supported
-    -   Definition:
-        -   Issues **actively triaged**, regressions **block** the release
-    -   Last 2 major versions of Chrome, Firefox, and Edge on desktop OSes
-    -   Last 2 versions of Safari
-    -   Latest release of official Element Desktop app on desktop OSes
-    -   Desktop OSes means macOS, Windows, and Linux versions for desktop devices
-        that are actively supported by the OS vendor and receive security updates
--   Best effort
-    -   Definition:
-        -   Issues **accepted**, regressions **do not block** the release
-        -   The wider Element Products(including Element Call and the Enterprise Server Suite) do still not officially support these browsers.
-        -   The element web project and its contributors should keep the client functioning and gracefully degrade where other sibling features (E.g. Element Call) may not function.
-    -   Last major release of Firefox ESR and Chrome/Edge Extended Stable
--   Community Supported
-    -   Definition:
-        -   Issues **accepted**, regressions **do not block** the release
-        -   Community contributions are welcome to support these issues
-    -   Mobile web for current stable version of Chrome, Firefox, and Safari on Android, iOS, and iPadOS
--   Not supported
-    -   Definition: Issues only affecting unsupported environments are **closed**
-    -   Everything else
+- Supported
+    - Definition:
+        - Issues **actively triaged**, regressions **block** the release
+    - Last 2 major versions of Chrome, Firefox, and Edge on desktop OSes
+    - Last 2 versions of Safari
+    - Latest release of official Element Desktop app on desktop OSes
+    - Desktop OSes means macOS, Windows, and Linux versions for desktop devices
+      that are actively supported by the OS vendor and receive security updates
+- Best effort
+    - Definition:
+        - Issues **accepted**, regressions **do not block** the release
+        - The wider Element Products(including Element Call and the Enterprise Server Suite) do still not officially support these browsers.
+        - The element web project and its contributors should keep the client functioning and gracefully degrade where other sibling features (E.g. Element Call) may not function.
+    - Last major release of Firefox ESR and Chrome/Edge Extended Stable
+- Community Supported
+    - Definition:
+        - Issues **accepted**, regressions **do not block** the release
+        - Community contributions are welcome to support these issues
+    - Mobile web for current stable version of Chrome, Firefox, and Safari on Android, iOS, and iPadOS
+- Not supported
+    - Definition: Issues only affecting unsupported environments are **closed**
+    - Everything else
 
 The period of support for these tiers should last until the releases specified above, plus 1 app release cycle(2 weeks). In the case of Firefox ESR this is extended further to allow it land in Debian Stable.
 
@@ -74,16 +74,16 @@ situation, but it's still not good practice to do it in the first place. See
 Unless you have special requirements, you will want to add the following to
 your web server configuration when hosting Element Web:
 
--   The `X-Frame-Options: SAMEORIGIN` header, to prevent Element Web from being
-    framed and protect from [clickjacking][owasp-clickjacking].
--   The `frame-ancestors 'self'` directive to your `Content-Security-Policy`
-    header, as the modern replacement for `X-Frame-Options` (though both should be
-    included since not all browsers support it yet, see
-    [this][owasp-clickjacking-csp]).
--   The `X-Content-Type-Options: nosniff` header, to [disable MIME
-    sniffing][mime-sniffing].
--   The `X-XSS-Protection: 1; mode=block;` header, for basic XSS protection in
-    legacy browsers.
+- The `X-Frame-Options: SAMEORIGIN` header, to prevent Element Web from being
+  framed and protect from [clickjacking][owasp-clickjacking].
+- The `frame-ancestors 'self'` directive to your `Content-Security-Policy`
+  header, as the modern replacement for `X-Frame-Options` (though both should be
+  included since not all browsers support it yet, see
+  [this][owasp-clickjacking-csp]).
+- The `X-Content-Type-Options: nosniff` header, to [disable MIME
+  sniffing][mime-sniffing].
+- The `X-XSS-Protection: 1; mode=block;` header, for basic XSS protection in
+  legacy browsers.
 
 [mime-sniffing]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing
 [owasp-clickjacking-csp]: https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html#content-security-policy-frame-ancestors-examples

code_style.md

@@ -3,9 +3,9 @@
 This code style applies to projects which the element-web team directly maintains or is reasonably
 adjacent to. As of writing, these are:
 
--   element-desktop
--   element-web
--   matrix-js-sdk
+- element-desktop
+- element-web
+- matrix-js-sdk
 
 Other projects might extend this code style for increased strictness. For example, matrix-events-sdk
 has stricter code organization to reduce the maintenance burden. These projects will declare their code

docs/SUMMARY.md

@@ -1,55 +1,55 @@
 # Summary
 
--   [Introduction](../README.md)
+- [Introduction](../README.md)
 
 # Usage
 
--   [Betas](betas.md)
--   [Labs](labs.md)
+- [Betas](betas.md)
+- [Labs](labs.md)
 
 # Setup
 
--   [Install](install.md)
--   [Config](config.md)
--   [Custom home page](custom-home.md)
--   [Kubernetes](kubernetes.md)
--   [Jitsi](jitsi.md)
--   [Encryption](e2ee.md)
+- [Install](install.md)
+- [Config](config.md)
+- [Custom home page](custom-home.md)
+- [Kubernetes](kubernetes.md)
+- [Jitsi](jitsi.md)
+- [Encryption](e2ee.md)
 
 # Build
 
--   [Customisations](customisations.md)
--   [Modules](modules.md)
--   [Native Node modules](native-node-modules.md)
+- [Customisations](customisations.md)
+- [Modules](modules.md)
+- [Native Node modules](native-node-modules.md)
 
 # Contribution
 
--   [Choosing an issue](choosing-an-issue.md)
--   [Translation](translating.md)
--   [Netlify builds](pr-previews.md)
--   [Code review](review.md)
+- [Choosing an issue](choosing-an-issue.md)
+- [Translation](translating.md)
+- [Netlify builds](pr-previews.md)
+- [Code review](review.md)
 
 # Development
 
--   [App load order](app-load.md)
--   [Translation](translating-dev.md)
--   [Theming](theming.md)
--   [Playwright end to end tests](playwright.md)
--   [Memory profiling](memory-profiles-and-leaks.md)
--   [Jitsi](jitsi-dev.md)
--   [Feature flags](feature-flags.md)
--   [OIDC and delegated authentication](oidc.md)
--   [Release Process](release.md)
+- [App load order](app-load.md)
+- [Translation](translating-dev.md)
+- [Theming](theming.md)
+- [Playwright end to end tests](playwright.md)
+- [Memory profiling](memory-profiles-and-leaks.md)
+- [Jitsi](jitsi-dev.md)
+- [Feature flags](feature-flags.md)
+- [OIDC and delegated authentication](oidc.md)
+- [Release Process](release.md)
 
 # Deep dive
 
--   [Skinning](skinning.md)
--   [Cider editor](ciderEditor.md)
--   [Iconography](icons.md)
--   [Jitsi](jitsi.md)
--   [Local echo](local-echo-dev.md)
--   [Media](media-handling.md)
--   [Room List Store](room-list-store.md)
--   [Scrolling](scrolling.md)
--   [Usercontent](usercontent.md)
--   [Widget layouts](widget-layouts.md)
+- [Skinning](skinning.md)
+- [Cider editor](ciderEditor.md)
+- [Iconography](icons.md)
+- [Jitsi](jitsi.md)
+- [Local echo](local-echo-dev.md)
+- [Media](media-handling.md)
+- [Room List Store](room-list-store.md)
+- [Scrolling](scrolling.md)
+- [Usercontent](usercontent.md)
+- [Widget layouts](widget-layouts.md)

docs/app-load.md

@@ -61,18 +61,18 @@ flowchart TD
 
 Key:
 
--   Parallelogram: async/await task
--   Box: sync task
--   Diamond: conditional branch
--   Circle: user interaction
--   Blue arrow: async task is allowed to settle but allowed to fail
--   Red arrow: async task success is asserted
+- Parallelogram: async/await task
+- Box: sync task
+- Diamond: conditional branch
+- Circle: user interaction
+- Blue arrow: async task is allowed to settle but allowed to fail
+- Red arrow: async task success is asserted
 
 Notes:
 
--   A task begins when all its dependencies (arrows going into it) are fulfilled.
--   The success of setting up rageshake is never asserted, element-web has a fallback path for running without IDB (and thus rageshake).
--   Everything is awaited to be settled before the Modernizr check, to allow it to make use of things like i18n if they are successful.
+- A task begins when all its dependencies (arrows going into it) are fulfilled.
+- The success of setting up rageshake is never asserted, element-web has a fallback path for running without IDB (and thus rageshake).
+- Everything is awaited to be settled before the Modernizr check, to allow it to make use of things like i18n if they are successful.
 
 Underlying dependencies:
 

docs/choosing-an-issue.md

@@ -32,19 +32,19 @@ someone to add something.
 When you're looking through the list, here are some things that might make an
 issue a **GOOD** choice:
 
--   It is a problem or feature you care about.
--   It concerns a type of code you know a little about.
--   You think you can understand what's needed.
--   It already has approval from Element Web's designers (look for comments from
-    members of the
-    [Product](https://github.com/orgs/element-hq/teams/product/members) or
-    [Design](https://github.com/orgs/element-hq/teams/design/members) teams).
+- It is a problem or feature you care about.
+- It concerns a type of code you know a little about.
+- You think you can understand what's needed.
+- It already has approval from Element Web's designers (look for comments from
+  members of the
+  [Product](https://github.com/orgs/element-hq/teams/product/members) or
+  [Design](https://github.com/orgs/element-hq/teams/design/members) teams).
 
 Here are some things that might make it a **BAD** choice:
 
--   You don't understand it (maybe add a comment asking a clarifying question).
--   It sounds difficult, or is part of a larger change you don't know about.
--   **It is tagged with `X-Needs-Design` or `X-Needs-Product`.**
+- You don't understand it (maybe add a comment asking a clarifying question).
+- It sounds difficult, or is part of a larger change you don't know about.
+- **It is tagged with `X-Needs-Design` or `X-Needs-Product`.**
 
 **Element Web's Design and Product teams tend to be very busy**, so if you make
 changes that require approval from one of those teams, you will probably have