Avoid soft breaks

Author: RichDom2185

docs/src/repotools/6-docserver/1-overview.md

@@ -3,17 +3,15 @@ title: Overview
 ---
 # Developer Documentation Server
 
-Originally most of the developer documentation was contained within the Github repository's wiki. However, as the documentation became more comprehensive in scope and complex in design,
-it was necessary to migrate to a more advanced and configurable solution.
+Originally most of the developer documentation was contained within the Github repository's wiki. However, as the documentation became more comprehensive in scope and complex in design, it was necessary to migrate to a more advanced and configurable solution.
 
 This documentation server is powered by [Vitepress](https://vitepress.dev), which takes Markdown files and renders them into a (mostly) static site.
 
 ## File Structure
 
 All pages for the server are contained under `src`.
 
-[`vitepress-sidebar`](https://vitepress-sidebar.cdget.com) is being used to generate the sidebar for the server. This means that entries in the sidebar appear sorted according to the file/folder names from which they originate. This is why
-some folder have contents that are labelled `1-something`, `2-something` etc. Each item's value is taken from file's frontmatter, or if not present, the file's first header.
+[`vitepress-sidebar`](https://vitepress-sidebar.cdget.com) is being used to generate the sidebar for the server. This means that entries in the sidebar appear sorted according to the file/folder names from which they originate. This is why some folder have contents that are labelled `1-something`, `2-something` etc. Each item's value is taken from file's frontmatter, or if not present, the file's first header.
 
 Folders produce item groups, the name of which can be customized using an `index.md` file within that folder.
 
@@ -50,8 +48,7 @@ The above file structure produces the menu below:
 
 Each item takes its title value from either the frontmatter (if available) or the first heading of each page.
 
-`index.md` files are only used to title the menus, they are not intended for navigation, though are navigable to if the user enters the address manually, so it is still recommended to keep some basic
-documentation in those pages or create rewrites so that users are automatically redirected away from those pages. Here are the contents of <nobr><code>2-bundle/index.md</code></nobr>:
+`index.md` files are only used to title the menus, they are not intended for navigation, though are navigable to if the user enters the address manually, so it is still recommended to keep some basic documentation in those pages or create rewrites so that users are automatically redirected away from those pages. Here are the contents of <nobr><code>2-bundle/index.md</code></nobr>:
 
 <<< ../../modules/2-bundle/index.md
 
@@ -62,21 +59,18 @@ Instead, the links in the sidebar link to the page (if it is a markdown file), o
 The documentation for `@sourceacademy/modules-lib` is automatically generated by Typedoc. The configuration options for this generation are found in that folder. The documentation for `@sourceacademy/modules-lib` should be built before this server is built.
 
 ::: details help pls
-Supposedly Vitepress can embed React components, which would be nice for us to have working demonstrations of our React components. Unfortunately, I have never
-been able to get that to work. You can start [here](https://github.com/vuejs/vitepress/discussions/2183) if you want to help figure this out.
+Supposedly Vitepress can embed React components, which would be nice for us to have working demonstrations of our React components. Unfortunately, I have never been able to get that to work. You can start [here](https://github.com/vuejs/vitepress/discussions/2183) if you want to help figure this out.
 :::
 
 ## Diagrams
 
-Diagrams (such as the one seen [here](/buildtools/4-resolution.html#bundle-resolution)) are supported via the [`mermaid`](https://mermaid.js.org) rendering engine and provided with the [Vitepress plugin for mermaid](https://github.com/emersonbottero/vitepress-plugin-mermaid).
-Simply use a Markdown code block with the `mermaid` language tag.
+Diagrams (such as the one seen [here](/buildtools/4-resolution.html#bundle-resolution)) are supported via the [`mermaid`](https://mermaid.js.org) rendering engine and provided with the [Vitepress plugin for mermaid](https://github.com/emersonbottero/vitepress-plugin-mermaid). Simply use a Markdown code block with the `mermaid` language tag.
 
 ## Code Snippets
 
 `vitepress` provides the ability for a Markdown document to "import" a code snippet from an external file. This function is documented [here](https://vitepress.dev/guide/markdown#import-code-snippets).
 
-Throughout many files in the repository, you will see VSCode `#region` comments. These comments are used to mark out a VSCode region in Typescript/Javascript and are used by the doc server to extract only
-a specified portion of the code within the file. Do not remove these comments unless absolutely necessary.
+Throughout many files in the repository, you will see VSCode `#region` comments. These comments are used to mark out a VSCode region in Typescript/Javascript and are used by the doc server to extract only a specified portion of the code within the file. Do not remove these comments unless absolutely necessary.
 
 ## Tree Diagrams
 
@@ -94,8 +88,6 @@ are generated via their own markdown plugin, the details of which can be found [
 
 ## Production Build and Dead Links
 
-The preview version of the docs rendered by Vitepress when the `vitepress dev` command is executed is not the final version that is intended to be displayed.
-For this, Vitepress provides the `vitepress build` command, which converts the documentation source into its final, minified HTML form.
+The preview version of the docs rendered by Vitepress when the `vitepress dev` command is executed is not the final version that is intended to be displayed. For this, Vitepress provides the `vitepress build` command, which converts the documentation source into its final, minified HTML form.
 
-As part of this process, Vitepress will highlight any "dead" links (i.e links that don't point to anything) and will fail if it finds any. If you're editing
-the documentation, you should run the build command to check for the dead links before pushing to the repository.
+As part of this process, Vitepress will highlight any "dead" links (i.e links that don't point to anything) and will fail if it finds any. If you're editing the documentation, you should run the build command to check for the dead links before pushing to the repository.

docs/src/repotools/6-docserver/2-dirtree.md

@@ -3,11 +3,9 @@
 The idea behind this plugin was inspired by [this](https://tree.nathanfriend.com/?) ASCII tree generator.
 
 ::: details Creating a Markdown-It Plugin
-The documentation for developers looking to create a Markdown-It plugin are woefully inadequate. Thus, most of this plugin was written
-based on the implementations of other plugins, such as the Vitepress Mermaid plugin and Vitepress Code snippet plugin.
+The documentation for developers looking to create a Markdown-It plugin are woefully inadequate. Thus, most of this plugin was written based on the implementations of other plugins, such as the Vitepress Mermaid plugin and Vitepress Code snippet plugin.
 
-It basically works by detecting when a code block has been assigned the `dirtree` language, parses the code block's content
-as YAML and converts that object into the directory structure that can then be rendered as text.
+It basically works by detecting when a code block has been assigned the `dirtree` language, parses the code block's content as YAML and converts that object into the directory structure that can then be rendered as text.
 
 Using the `languageAlias` markdown configuration, we can get Vitepress to highlight and colour the rendered directory trees.
 :::
@@ -28,8 +26,7 @@ name: root directory
 ```
 ````
 
-If you do not specify a name for your root directory, then it will have the default name of `"root"`. Now you can proceed to create
-children elements using a YAML list:
+If you do not specify a name for your root directory, then it will have the default name of `"root"`. Now you can proceed to create children elements using a YAML list:
 
 ````md
 ``` dirtree
@@ -42,8 +39,7 @@ children:
 ```
 ````
 
-Each item can either just be a string entry (like `item0` above), in which case that entry is simply displayed as is, or it can be a
-compound YAML object like `item1` is. The details for such an entry are as follows:
+Each item can either just be a string entry (like `item0` above), in which case that entry is simply displayed as is, or it can be a compound YAML object like `item1` is. The details for such an entry are as follows:
 
 ```yml
 name: item1  # You must provide the name property
@@ -71,8 +67,7 @@ children:
 
 ## Path Validation
 
-In the case you intend for your displayed directory tree to reflect the structure of an actual directory on disk,
-you can specify a `path` property on the root object. This path is resolved from the file containing the markdown.
+In the case you intend for your displayed directory tree to reflect the structure of an actual directory on disk, you can specify a `path` property on the root object. This path is resolved from the file containing the markdown.
 
 ````md {4}
 <!-- Located in docs/index.md -->
@@ -87,16 +82,12 @@ children:
 ```
 ````
 
-The plugin will then traverse down the directory structure. For each item, if it has children, it checks that the item corresponds
-to a directory of the same name on disk. In the example above, the plugin would check that `docs/root` was a folder that contained
-either a file or directory called `item0`.
+The plugin will then traverse down the directory structure. For each item, if it has children, it checks that the item corresponds to a directory of the same name on disk. In the example above, the plugin would check that `docs/root` was a folder that contained either a file or directory called `item0`.
 
-It would also check that `docs/root/item1` exists and that is is a directory (since it has children elements). This check is recursively
-performed on each subdirectory.
+It would also check that `docs/root/item1` exists and that is is a directory (since it has children elements). This check is recursively performed on each subdirectory.
 
 > [!WARNING]
-> This validation is only performed for items that have been specified in the `dirtree`, i.e. it doesn't consider items that are present
-> on disk but aren't listed as an issue.
+> This validation is only performed for items that have been specified in the `dirtree`, i.e. it doesn't consider items that are present on disk but aren't listed as an issue.
 
 If the check fails a warning will be printed to the console stating which files it wasn't able to locate.
 

docs/src/repotools/7-workflows/1-actions.md

@@ -10,8 +10,7 @@ makes use of two:
 - Initializer Action
 - Information Action
 
-Creating custom actions is detailed [here](https://docs.github.com/en/actions/reference/workflows-and-actions/metadata-syntax). The convention for each action is have its metadata file (`action.yml`) in the same
-directory as its source code (if necessary).
+Creating custom actions is detailed [here](https://docs.github.com/en/actions/reference/workflows-and-actions/metadata-syntax). The convention for each action is have its metadata file (`action.yml`) in the same directory as its source code (if necessary).
 
 ## Information Action (`info/action.yml`)
 
@@ -24,8 +23,7 @@ The information action retrieves information about each package present in the r
 
 In the case of bundles or tabs, it also retrieves the name of the bundle or tab.
 
-In case of changes to the lockfile, it also determines which packages need to be rebuilt. This can happen when dependencies of dependencies change,
-so no change is present in the package's source code itself, but the lockfile itself has changed.
+In case of changes to the lockfile, it also determines which packages need to be rebuilt. This can happen when dependencies of dependencies change, so no change is present in the package's source code itself, but the lockfile itself has changed.
 
 This information is used by both the initializer action and the workflows to determine the what tasks need to be executed.
 

docs/src/repotools/7-workflows/2-pull-request.md

@@ -10,36 +10,29 @@ This workflow makes use of `matrix` strategy to run the tasks in parallel where
 
 ## 1. `find-packages`
 
-This job executes first, using the [Information Action](./1-actions.md#information-action-infoactionyml). The action returns
-all the necessary information for the subsequent jobs to execute their tasks.
+This job executes first, using the [Information Action](./1-actions.md#information-action-infoactionyml). The action returns all the necessary information for the subsequent jobs to execute their tasks.
 
 > [!INFO]
 > The info action runs `git --no-pager diff master [directory]` from a package's root directory to determine if there
 > are any changes in the package. Because of this, it is also necessary to run a `git fetch`.
 
 ## 2. `libraries`, `bundles` and `tabs`
 
-These three jobs are matrix jobs that run tasks for the individual packages. If the package has changes, then
-the job will run tests and `tsc` for the package.
+These three jobs are matrix jobs that run tasks for the individual packages. If the package has changes, then the job will run tests and `tsc` for the package.
 
 This means that if the package requires `playwright` to run its tests, it will be installed during the init step.
 
-These jobs have the `fail-fast` option set to `false`, so a single job failing doesn't mean that the rest of the jobs
-in the workflow get cancelled.
+These jobs have the `fail-fast` option set to `false`, so a single job failing doesn't mean that the rest of the jobs in the workflow get cancelled.
 
-For libraries in particular, the job is run with both the `ubuntu-latest` and `windows-latest` OSes. This makes sure that
-our libraries are compatibile with both Windows and POSIX-Compliant operating systems.
+For libraries in particular, the job is run with both the `ubuntu-latest` and `windows-latest` OSes. This makes sure that our libraries are compatibile with both Windows and POSIX-Compliant operating systems.
 
 ## 3. `devserver`
 
-The `devserver` jobs only executes if there were changes within the dev server. Since it relies on bundles and tabs being
-compiled, it does rely on both the `bundles` and the `tabs` jobs to have completed.
+The `devserver` jobs only executes if there were changes within the dev server. Since it relies on bundles and tabs being compiled, it does rely on both the `bundles` and the `tabs` jobs to have completed.
 
 ## 4. `docserver`
 
-The `docserver` job only executes if there were changes made to the modules library or the docs themselves. It doesn't
-deploy the docs here, so it the call to `yarn build` only serves as to way to check that the docs can be generated without errors
-like dead links.
+The `docserver` job only executes if there were changes made to the modules library or the docs themselves. It doesn't deploy the docs here, so it the call to `yarn build` only serves as to way to check that the docs can be generated without errors like dead links.
 
 ## 5. `repo-tasks`