style: Enforce linting rules on markdown files

* chore: add markdownlint-cli2 and config for mkdocs

* style: enforce linting rules on mkdocs md files

* chore: tweaks to markdownlint rules

* style: linting changelog

* style: linting release notes

* style: linting .github md files

* style: further linting of docs

* style: linting readmes

* chore: update linting script entries

* docs: tweak release after rebase

* chore: simplify root md linting config

* chore: extend base config

* chore: implement requested changes

* chore: remove unnecessary exception

* chore: fix comment type

* styling: single config + list spacing

* chore: implement requested changes

* chore: use .cjs files for markdownlint config

* chore: implement requested changes

.github/.markdownlint-cli2.cjs

@@ -0,0 +1,14 @@
+
+const options = require('../.markdownlint-cli2.cjs');
+"use strict";
+
+module.exports = {
+  globs: [ "**/*.md" ],
+  config: {
+    // Re-use the base config
+    ...options.config,
+
+    // Allow first line to not be top level heading
+    MD041: false
+  }
+};

.github/ISSUE_TEMPLATE/bug-report.md

@@ -8,7 +8,9 @@ assignees: ''
 ---
 
 #### Environment
-- Server version: *Output of `community-solid-server --version` for a global or `npx community-solid-server --version` for a local installation*
+
+- Server version: *Output of `community-solid-server --version` for a
+  global or `npx community-solid-server --version` for a local installation*
 - Node.js version: *Output of `node -v`*
 - npm version: *Output of `npm -v`*
 

.github/ISSUE_TEMPLATE/feature-request.md

@@ -7,7 +7,7 @@ assignees: ''
 
 ---
 
-#### Feature description:
+#### Feature description
 
 <!--In case you want to start a discussion about an idea, discussions are better suited for this https://github.com/CommunitySolidServer/CommunitySolidServer/discussions -->
 <!--A clear and concise description of what you want to happen.-->

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,6 +1,6 @@
 #### 📁 Related issues
 
-<!-- 
+<!--
 Reference any relevant issues here. Closing keywords only have an effect when targeting the main branch. If there are no related issues, you must first create an issue through https://github.com/CommunitySolidServer/CommunitySolidServer/issues/new/choose
 -->
 
@@ -8,16 +8,16 @@ Reference any relevant issues here. Closing keywords only have an effect when ta
 
 <!-- Describe the relevant changes in this PR. Also add notes that might be relevant for code reviewers. -->
 
-
 ### ✅ PR check list
 
 Before this pull request can be merged, a core maintainer will check whether
-  * [ ] this PR is labeled with the correct semver label
+
-    - semver.patch: Backwards compatible bug fixes.
+* [ ] this PR is labeled with the correct semver label
-    - semver.minor: Backwards compatible feature additions.
+    * semver.patch: Backwards compatible bug fixes.
-    - semver.major: Breaking changes. This includes changing interfaces or configuration behaviour.
+    * semver.minor: Backwards compatible feature additions.
-  * [ ] the correct branch is targeted. Patch updates can target main, other changes should target the latest versions/* branch.
+    * semver.major: Breaking changes. This includes changing interfaces or configuration behaviour.
-  * [ ] the RELEASE_NOTES.md document in case of relevant feature or config changes.
+* [ ] the correct branch is targeted. Patch updates can target main, other changes should target the latest versions/* branch.
-  * [ ] any relevant documentation was updated to reflect the changes in this PR.
+* [ ] the RELEASE_NOTES.md document in case of relevant feature or config changes.
+* [ ] any relevant documentation was updated to reflect the changes in this PR.
 
 <!-- Try to check these to the best of your abilities before opening the PR -->

.markdownlint-cli2.cjs

@@ -0,0 +1,31 @@
+"use strict";
+
+module.exports = {
+  ignores: [ "node_modules/", "LICENSE.md" ],
+
+  globs: [ "**/*.md" ],
+
+  config: {
+    // Enable all markdownlint rules
+    default: true,
+
+    // Set list indent level to 4 which mkdocs / Python-Markdown requires
+    MD007: { "indent": 4 },
+
+    // Enable line length check but exclude tables and code blocks
+    MD013: {
+      line_length: 120,
+      tables: false,
+      code_blocks: false
+    },
+
+    // Allow multiple subheadings with the same content
+    // across different section (#1 ##A ##B #2 ##A ##B)
+    MD024: {
+      allow_different_nesting: true
+    },
+
+    // Set Ordered list item prefix to "ordered" (use 1. 2. 3. not 1. 1. 1.)
+    MD029: { "style": "ordered" }
+  }
+};

.versionrc.json

@@ -10,6 +10,6 @@
         {"type": "perf", "section": "Performance"},
         {"type": "test", "section": "Testing"}
     ],
-    "header": "# Changelog\n\nAll notable changes to this project will be documented in this file.",
+    "header": "<!-- markdownlint-disable MD013 -->\n# Changelog\n\nAll notable changes to this project will be documented in this file.",
     "releaseCommitMessageFormat": "chore(release): Release version {{currentTag}} of the npm package"
 }

CHANGELOG.md

@@ -1,6 +1,8 @@
+<!-- markdownlint-disable MD013 -->
 # Changelog
 
 All notable changes to this project will be documented in this file.
+
 ## [5.0.0](https://github.com/CommunitySolidServer/CommunitySolidServer/compare/v4.0.1...v5.0.0) (2022-08-08)
 
 ### Features
@@ -277,16 +279,16 @@ All notable changes to this project will be documented in this file.
 
 ## [1.0.0](https://github.com/solid/community-server/compare/v1.0.0-beta.2...v1.0.0) (2021-08-04)
 
-## Added
+### Added
 
 * feat: Create ChainedTemplateEngine for combining engines ([18a7103](https://github.com/solid/community-server/commit/18a71032c0ba872a3acd08fa1c63136fdf6489de))
 * feat: Accept asset paths as config. ([f28279e](https://github.com/solid/community-server/commit/f28279e3a577072adb9ff27b2a54a1624076a448))
 
-## Changed
+### Changed
 
 * change: Use @css: instead of $PACKAGE_ROOT/ ([1719857](https://github.com/solid/community-server/commit/1719857e4b340fd16cdde9d9a45097072cc68fe2))
 
-## Fixed
+### Fixed
 
 * fix: Replace rimraf with fs-extra.remove ([2a82c4f](https://github.com/solid/community-server/commit/2a82c4f06e25981205d0841fe473d038888bc3ef))
 

CODE_OF_CONDUCT.md

@@ -1 +1,3 @@
+# Code of conduct
+
 We follow and adhere to the Solid [Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md).

README.md

@@ -1,6 +1,7 @@
 # Community Solid Server
 
-<img src="https://raw.githubusercontent.com/CommunitySolidServer/CommunitySolidServer/main/templates/images/solid.svg" alt="[Solid logo]" height="150" align="right"/>
+<img src="https://raw.githubusercontent.com/CommunitySolidServer/CommunitySolidServer/main/templates/images/solid.svg"
+ alt="[Solid logo]" height="150" align="right"/>
 
 [![MIT license](https://img.shields.io/npm/l/@solid/community-server)](https://github.com/CommunitySolidServer/CommunitySolidServer/blob/main/LICENSE.md)
 [![npm version](https://img.shields.io/npm/v/@solid/community-server)](https://www.npmjs.com/package/@solid/community-server)
@@ -30,15 +31,16 @@ And, of course, for many others who like to experience Solid.
 You can install the software locally or on your server
 and get started with Solid immediately.
 
-
 ## ⚡ Running the server
+
 To run the server, you will need [Node.js](https://nodejs.org/en/).
 We support versions 14.2 and up.
-<br>
+
 If you do not use Node.js,
 you can run a [Docker](https://www.docker.com/) version instead.
 
 ### 💻 Installing and running locally
+
 After installing Node.js,
 install the latest server version
 from the [npm package repository](https://www.npmjs.com/):
@@ -48,19 +50,23 @@ npm install -g @solid/community-server
 ```
 
 To run the server with in-memory storage, use:
+
 ```shell
 community-solid-server # add parameters if needed
 ```
 
 To run the server with your current folder as storage, use:
+
 ```shell
 community-solid-server -c @css:config/file.json
 ```
 
 ### 📃 Installing and running from source
+
 If you rather prefer to run the latest source code version,
 or if you want to try a specific [branch](https://www.npmjs.com/) of the code,
 you can use:
+
 ```shell
 git clone https://github.com/CommunitySolidServer/CommunitySolidServer.git
 cd CommunitySolidServer
@@ -69,7 +75,9 @@ npm start -- # add parameters if needed
 ```
 
 ### 📦 Running via Docker
-Docker allows you to run the server without having Node.js installed. Images are built on each tagged version and hosted on [Docker Hub](https://hub.docker.com/r/solidproject/community-server).
+
+Docker allows you to run the server without having Node.js installed. Images are built on each tagged version and hosted
+on [Docker Hub](https://hub.docker.com/r/solidproject/community-server).
 
 ```shell
 # Clone the repo to get access to the configs
@@ -86,15 +94,20 @@ docker run --rm -v ~/Solid:/data -p 3000:3000 -it -e CSS_CONFIG=config/file-no-s
 ```
 
 ### 🗃️ Helm Chart
-The official [Helm](https://helm.sh/) Chart for Kubernetes deployment is maintained at [CommunitySolidServer/css-helm-chart](https://github.com/CommunitySolidServer/css-helm-chart) and published on [ArtifactHUB](https://artifacthub.io/packages/helm/community-solid-server/community-solid-server). There you will find complete installation instructions.
 
-```
+The official [Helm](https://helm.sh/) Chart for Kubernetes deployment is maintained at
+[CommunitySolidServer/css-helm-chart](https://github.com/CommunitySolidServer/css-helm-chart) and published on
+[ArtifactHUB](https://artifacthub.io/packages/helm/community-solid-server/community-solid-server).
+There you will find complete installation instructions.
+
+```shell
 # Summary
 helm repo add community-solid-server https://communitysolidserver.github.io/css-helm-chart/charts/
 helm install my-css community-solid-server/community-solid-server
 ```
 
 ## 🔧 Configuring the server
+
 The Community Solid Server is designed to be flexible
 such that people can easily run different configurations.
 This is useful for customizing the server with plugins,
@@ -103,6 +116,7 @@ or developing new parts for the server
 without needing to change its base code.
 
 ### ⏱️ Parameters
+
 An easy way to customize the server is
 by passing parameters to the server command.
 These parameters give you direct access
@@ -123,7 +137,10 @@ to some commonly used settings:
 | `--workers, -w`        | `1`                        | Run in multithreaded mode using workers. Special values are `-1` (scale to `num_cores-1`), `0` (scale to `num_cores`) and 1 (singlethreaded).     |
 
 ### 🔀 Multithreading
-The Community Solid Server can be started in multithreaded mode with any config. The config must only contain components that are threadsafe though. If a non-threadsafe component is used in multithreaded mode, the server will describe with an error which class is the culprit.
+
+The Community Solid Server can be started in multithreaded mode with any config. The config must only contain components
+that are threadsafe though. If a non-threadsafe component is used in multithreaded mode, the server will describe with
+an error which class is the culprit.
 
 ```node
 # Running multithreaded with autoscaling to number of logical cores minus 1
@@ -131,7 +148,8 @@ npm start -- -c config/file.json -w -1
 ```
 
 ### 🖥️ Environment variables
-Parameters can also be passed through environment variables. 
+
+Parameters can also be passed through environment variables.
 
 They are prefixed with `CSS_` and converted from `camelCase` to `CAMEL_CASE`
 
@@ -140,6 +158,7 @@ They are prefixed with `CSS_` and converted from `camelCase` to `CAMEL_CASE`
 **Note: command-line arguments will always override environment variables!**
 
 ### 🧶 Custom configurations
+
 More substantial changes to server behavior can be achieved
 by writing new configuration files in JSON-LD.
 The Community Solid Server uses [Components.js](https://componentsjs.readthedocs.io/en/latest/)
@@ -150,8 +169,8 @@ are available in the [`config` folder](https://github.com/CommunitySolidServer/C
 
 Recipes for configuring the server can be found at [CommunitySolidServer/recipes](https://github.com/CommunitySolidServer/recipes).
 
-
 ## 👩🏽‍💻 Developing server code
+
 The server allows writing and plugging in custom modules
 without altering its base source code.
 
@@ -163,8 +182,8 @@ If you want to help out with server development,
 have a look at the [📓 user documentation](https://communitysolidserver.github.io/CommunitySolidServer/) and
 [🛠️ good first issues](https://github.com/CommunitySolidServer/CommunitySolidServer/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22).
 
-
 ## 📜 License
+
 The Solid Community Server code
 is copyrighted by [Inrupt Inc.](https://inrupt.com/)
 and [imec](https://www.imec-int.com/)
@@ -177,8 +196,8 @@ Core contributors are
 and
 [Matthieu Bosquet](https://github.com/matthieubosquet).
 
-
 ## 🎤 Feedback and questions
+
 Don't hesitate to [start a discussion](https://github.com/CommunitySolidServer/CommunitySolidServer/discussions)
 or [report a bug](https://github.com/CommunitySolidServer/CommunitySolidServer/issues).
 

RELEASE_NOTES.md

@@ -1,7 +1,9 @@
 # Community Solid Server release notes
 
 ## v5.0.0
+
 ### New features
+
 - Metadata of resources can now be edited by PATCHing its description resource.
   This has an impact on which requests are allowed.
   See the [documentation](https://communitysolidserver.github.io/CommunitySolidServer/5.x/usage/metadata/) for more information.
@@ -15,70 +17,76 @@
 - Support for Node v12 was dropped.
 
 ### Data migration
+
 No actions are required to migrate data.
 
 ### Configuration changes
+
 You might need to make changes to your v4 configuration if you use a custom config.
 
 The `@context` needs to be updated to
 `https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/^5.0.0/components/context.jsonld`.
 
 The following changes pertain to the imports in the default configs:
+
 - The prefix of all imports was changed from `files-scs` to `css`.
 - All default configurations with a file-based backend now use a file-based locker instead of a memory-based one,
   making them threadsafe.
 - 2 new options have been added for the `/http/server-factory/` imports: `https-websockets.json` and `https-no-websockets.json`,
   which allow starting the server with HTTPS by adding 2 new CLI parameters `httpsKey` and `httpsCert`.
-  - `/https-file-cli.json` was greatly simplified because of this change.
+    - `/https-file-cli.json` was greatly simplified because of this change.
 - `/sparql-file-storage.json` had several changes, simplifying how regexes can be used.
 
 The following changes are relevant for v4 custom configs that replaced certain features.
+
 - CLI parsing had several changes.
-  - `/app/variables/*`
+    - `/app/variables/*`
 - The `SingleThreadedResourceLocker` was renamed.
-  - `/util/resource-locker/memory.json`
+    - `/util/resource-locker/memory.json`
 - The content-length parser has been moved from the default configuration to the quota configurations.
-   - `/ldp/metadata-parser/default.json`
+    - `/ldp/metadata-parser/default.json`
-   - `/storage/backend/*-quota-file.json`
+    - `/storage/backend/*-quota-file.json`
-   - `/storage/backend/quota/*`
+    - `/storage/backend/quota/*`
 - Regex routing was updated to use ordered entries.
-   - `/storage/backend/regex.json`
+    - `/storage/backend/regex.json`
 - The `IdentityProviderFactory` inputs have been extended.
-  - `/identity/handler/provider-factory/identity.json`
+    - `/identity/handler/provider-factory/identity.json`
 - Restructured the init configs.
-  - `/app/init/*`
+    - `/app/init/*`
-  - `/app/main/default.json`
+    - `/app/main/default.json`
 - Added lock cleanup on server start.
-  - `/util/resource-locker/file.json`
+    - `/util/resource-locker/file.json`
-  - `/util/resource-locker/redis.json`
+    - `/util/resource-locker/redis.json`
 - Updated finalizers.
-  - `/app/identity/handler/account-store/default.json` 
+    - `/app/identity/handler/account-store/default.json`
-  - `/identity/ownership/token.json`
+    - `/identity/ownership/token.json`
-  - `/ldp/authorization/readers/access-checkers/agent-group.json`
+    - `/ldp/authorization/readers/access-checkers/agent-group.json`
-  - `/ldp/handler/*`
+    - `/ldp/handler/*`
 - `IntermediateModesExtractor` has been added to the `ModesExtractors`
-  - `/ldp/modes/default.json`
+    - `/ldp/modes/default.json`
 - The `PermissionReader` structure has changed to be more consistent.
-  - `/ldp/authorization/*`
+    - `/ldp/authorization/*`
 - Several components now take a `metadataStrategy` parameter to support the new metadata feature.
-  - `/ldp/handler/components/operation-handler.json`
+    - `/ldp/handler/components/operation-handler.json`
-  - `/storage/backend/*`
+    - `/storage/backend/*`
-- Generation of auxiliary link headers was updated. 
+- Generation of auxiliary link headers was updated.
-  - `/ldp/metadata-writer/writers/link-rel.json`
+    - `/ldp/metadata-writer/writers/link-rel.json`
 - The `ConstantMetadataWriter` that adds the `MS-Author-Via` header was removed
-  - `/ldp/metadata-writer/default.json`
+    - `/ldp/metadata-writer/default.json`
 - PATCHing related components were completely refactored.
-  - `/storage/middleware/stores/patching.json`
+    - `/storage/middleware/stores/patching.json`
 - The metadata auxiliary strategy was added to the default list of auxiliary strategies.
-  - `/util/auxiliary/*`
+    - `/util/auxiliary/*`
 - Parsing link headers became more flexible.
-  - `/ldp/metadata-parser/parsers/link.json`
+    - `/ldp/metadata-parser/parsers/link.json`
 
 ### Interface changes
+
 A new interface `SingleThreaded` has been added. This empty interface can be implemented to mark a component as not-threadsafe.
 When the CSS starts in multithreaded mode, it will error and halt if any SingleThreaded components are instantiated.
 
 These changes are relevant if you wrote custom modules for the server that depend on existing interfaces.
+
 - `YargsCliExtractor` was changed to now take as input an array of parameter objects.
 - `RedirectAllHttpHandler` was removed and fully replaced by `RedirectingHttpHandler`.
 - `SingleThreadedResourceLocker` has been renamed to `MemoryResourceLocker`.
@@ -86,10 +94,10 @@ These changes are relevant if you wrote custom modules for the server that depen
 - The `IdentityProviderFactory` and `ConvertingErrorHandler` now additionally take a `PreferenceParser` as input.
 - Error handlers now take the incoming `HttpRequest` as input instead of just the preferences.
 - Extended the initialization/finalization system:
-  * Introduced `Initializable` interface and `InitializableHandler` wrapper class.
+    - Introduced `Initializable` interface and `InitializableHandler` wrapper class.
-  * Introduced `Finalizer` abstract class and `FinalizableHandler` wrapper class.
+    - Introduced `Finalizer` abstract class and `FinalizableHandler` wrapper class.
-  * Changed type for `finalizer` attribute in `App` from `Finalizable` to `Finalizer` and updated the calling code in `App.stop()`.
+    - Changed type for `finalizer` attribute in `App` from `Finalizable` to `Finalizer` and updated the calling code in `App.stop()`.
-  * Removed the now obsolete `ParallelFinalizer` util class.
+    - Removed the now obsolete `ParallelFinalizer` util class.
 - Added a lock cleanup on initialize for lock implementations `RedisLocker` and `FileSystemResourceLocker`.
 - `ResourceStore` functions that change a resource now return metadata for every changed resource.
 - All permission related interfaces have changed to support permissions over multiple identifiers.
@@ -99,46 +107,56 @@ These changes are relevant if you wrote custom modules for the server that depen
 - Many patching related classes were changed.
 
 ## v4.1.0
+
 ### New features
+
 - Environment variables can be used instead of CLI arguments if preferred.
 
 ## v4.0.1
+
 Freezes the `oidc-provider` dependency to prevent a potential issue with the solid authn client
-as described in https://github.com/inrupt/solid-client-authn-js/issues/2103.
+as described in <https://github.com/inrupt/solid-client-authn-js/issues/2103>.
 
 ## v4.0.0
+
 ### New features
-- The server can be started with a new parameter to automatically generate accounts and pods, 
+
+- The server can be started with a new parameter to automatically generate accounts and pods,
   for more info see [here](https://communitysolidserver.github.io/CommunitySolidServer/4.x/seeding-pods/).
 - It is now possible to automate authentication requests using Client Credentials,
   for more info see [here](https://communitysolidserver.github.io/CommunitySolidServer/4.x/client-credentials/).
 - A new `RedirectingHttpHandler` class has been added which can be used to redirect certain URLs.
-- A new default configuration `config/https-file-cli.json` 
+- A new default configuration `config/https-file-cli.json`
   that can set the HTTPS parameters through the CLI has been added.
   This is also an example of how to add CLI parameters through a custom configuration.
-- A new RedisLocker has been added to replace the old RedisResourceLocker class. 
+- A new RedisLocker has been added to replace the old RedisResourceLocker class.
   It allows for true threadsafe read/write locking.
 
 ### Configuration changes
+
 You might need to make changes to your v3 configuration if you use a custom config.
 
 The `@context` needs to be updated to
 `https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/^4.0.0/components/context.jsonld`.
 
 The following changes pertain to the imports in the default configs:
+
 - ...
 
 The following changes are relevant for v3 custom configs that replaced certain features.
+
 - The key/value storage configs in `config/storage/key-value/*` have been changed to reduce config duplication.
   All storages there that were only relevant for 1 class have been moved to the config of that class.
-- Due to a parameter rename in `CombinedSettingsResolver`, 
+- Due to a parameter rename in `CombinedSettingsResolver`,
   `config/app/variables/resolver/resolver.json` has been updated.
 - The OIDC provider setup was changed to add client_credentials support.
-  - `/identity/handler/adapter-factory/webid.json`
+    - `/identity/handler/adapter-factory/webid.json`
-  - `/identity/handler/provider-factory/identity.json`
+    - `/identity/handler/provider-factory/identity.json`
 
 ### Interface changes
+
 These changes are relevant if you wrote custom modules for the server that depend on existing interfaces.
+
 - The output of `parseContentType` in `HeaderUtil` was changed to include parameters.
 - `PermissionReader`s take an additional `modes` parameter as input.
 - The `ResourceStore` function `resourceExists` has been renamed to `hasResource`
@@ -147,24 +165,27 @@ These changes are relevant if you wrote custom modules for the server that depen
 - `RepresentationMetadata` no longer accepts strings for predicates in any of its functions.
 - `CombinedSettingsResolver` parameter `computers` has been renamed to `resolvers`.
 - `IdentityProviderFactory` requires an additional `credentialStorage` parameter.
-- The `RedisResourceLocker` class has been removed and the `RedisLocker`class was added instead. 
+- The `RedisResourceLocker` class has been removed and the `RedisLocker`class was added instead.
  `RedisLocker` implements both the `ResourceLocker` and `ReadWriteLocker` interface.
 
 ## v3.0.0
+
 ### New features
+
 - The Identity Provider now uses the `webid` scope as required for Solid-OIDC.
-- The `VoidLocker` can be used to disable locking for development/testing purposes. 
+- The `VoidLocker` can be used to disable locking for development/testing purposes.
   This can be enabled by changing the `/config/util/resource-locker/` import to `debug-void.json`
 - Added support for setting a quota on the server. See the `config/quota-file.json` config for an example.
-- An official docker image is now built on each version tag and published at https://hub.docker.com/r/solidproject/community-server.
+- An official docker image is now built on each version tag and published at <https://hub.docker.com/r/solidproject/community-server>.
 - Added support for N3 Patch.
-- It is now possible to customize arguments to the `community-solid-server` command, 
+- It is now possible to customize arguments to the `community-solid-server` command,
   which enables passing custom variables to configurations and setting new default values.
-- The AppRunner functions have changed to require Components.js variables. 
+- The AppRunner functions have changed to require Components.js variables.
   This is important for anyone who starts the server from code.
 - When logging in, a consent screen will now provide information about the client.
 
 ### Data migration
+
 The following actions are required if you are upgrading from a v2 server and want to retain your data.
 
 Due to changes in the keys used by the IDP, you will need to delete the stored keys and sessions.
@@ -172,36 +193,43 @@ If you are using a file backend, delete the `.internal/idp/` folder in your data
 This will not delete the user accounts, but users will have to log in again.
 
 ### Configuration changes
+
 You might need to make changes to your v2 configuration if you use a custom config.
 
-The `@context` needs to be updated to 
+The `@context` needs to be updated to
 `https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/^3.0.0/components/context.jsonld`.
 
 The following changes pertain to the imports in the default configs:
+
 - A new configuration option needs to be imported:
-  - `/app/variables/default.json` contains everything related to parsing CLI arguments 
+    - `/app/variables/default.json` contains everything related to parsing CLI arguments
     and assigning values to variables.
 
 The following changes are relevant for v2 custom configs that replaced certain features.
+
 - Conversion has been simplified so most converters are part of the conversion chain:
-  - `/util/representation-conversion/default.json`
+    - `/util/representation-conversion/default.json`
 - The IDP settings have changed to support the latest Solid-OIDC draft.
-  - `/identity/handler/provider-factory/identity.json`
+    - `/identity/handler/provider-factory/identity.json`
 - Requests targeting the OIDC library now use a separate handler.
-  - `/http/handler/default.json`
+    - `/http/handler/default.json`
-  - `/identity/handler/default.json`
+    - `/identity/handler/default.json`
 - The architecture of IDP interaction handlers has completely changed to improve modularity
-  - `/identity/handler/interaction/*`
+    - `/identity/handler/interaction/*`
-  - `/identity/registration/*`
+    - `/identity/registration/*`
 
 ### Interface changes
+
 These changes are relevant if you wrote custom modules for the server that depend on existing interfaces.
-- `TypedRepresentationConverter` function signatures changed 
+
+- `TypedRepresentationConverter` function signatures changed
   and base functionality moved to `BaseTypedRepresentationConverter`.
 - Many changes to several components related to the IDP. This includes the HTML templates.
 
 ## v2.0.0
+
 ### New features
+
 - Pod owners always have Control access to resources stored in their Pod.
 - The server now offers a one-time setup upon first boot.
   This can be accessed by going to `/setup`.
@@ -221,43 +249,51 @@ These changes are relevant if you wrote custom modules for the server that depen
   E.g., `/idp/register/` works, `/idp/register` will error.
 
 ### Configuration changes
+
 You might need to make changes to your v1 configuration if you use a custom config.
 
 The following changes pertain to the imports in the default configs:
+
 - There are 2 new configuration options that for which a valid option needs to be imported:
-  - `/app/setup` determines how and if setup should be enabled.
+    - `/app/setup` determines how and if setup should be enabled.
-  - `/identity/access` determines if IDP access (e.g., registration) should be restricted
+    - `/identity/access` determines if IDP access (e.g., registration) should be restricted
-- The `/app/init/default.json` configuration no longer initializes the root container. 
+- The `/app/init/default.json` configuration no longer initializes the root container.
   This behaviour has been moved to the other options for `/app/init`.
 - `/ldp/permissions` changed to `/ldp/modes` and only has a default option now.
 
 The following changes are relevant for v1 custom configs that replaced certain features.
 The path indicates which JSON-LD files were impacted by the change.
-- `IdentityProviderHttpHandler` and `InteractionRoute` arguments have changed substantially. 
+
-  - `/identity/handler/default.json`
+- `IdentityProviderHttpHandler` and `InteractionRoute` arguments have changed substantially.
-  - `/identity/handler/interaction/*`
+    - `/identity/handler/default.json`
-  - `/identity/registration/*`.
+    - `/identity/handler/interaction/*`
-- All internal storage is now stored in the `/.internal/` container. 
+    - `/identity/registration/*`.
-  - `/storage/key-value/resource-store.json`. 
+- All internal storage is now stored in the `/.internal/` container.
-- Patching related classes have changed. 
+    - `/storage/key-value/resource-store.json`.
-  - `/storage/middleware/stores/patching.json`.
+- Patching related classes have changed.
+    - `/storage/middleware/stores/patching.json`.
 - `BasicRequestParser` now needs a `conditionsParser` argument.
-  - `/ldp/handler/components/request-parser.json`.
+    - `/ldp/handler/components/request-parser.json`.
-- `LinkTypeParser` has been renamed to `LinkRelParser` and now takes mappings as input. 
+- `LinkTypeParser` has been renamed to `LinkRelParser` and now takes mappings as input.
-  - `/ldp/metadata-parser/*`
+    - `/ldp/metadata-parser/*`
-- `ComposedAuxiliaryStrategy` `isRootRequired` has been renamed to `requiredInRoot`. 
+- `ComposedAuxiliaryStrategy` `isRootRequired` has been renamed to `requiredInRoot`.
-  - `/util/auxiliary/strategies/acl.json`.
+    - `/util/auxiliary/strategies/acl.json`.
-- Many changes to authentication and authorization structure. 
+- Many changes to authentication and authorization structure.
-  - Config `/ldp/authentication/*` and `/ldp/authorization/*`.
+    - Config `/ldp/authentication/*` and `/ldp/authorization/*`.
-- All `HttpHandler`s have been changed. 
+- All `HttpHandler`s have been changed.
-  - `/app/setup/handlers/setup.json`
+    - `/app/setup/handlers/setup.json`
-  - `/http/handler/default.json`
+    - `/http/handler/default.json`
-  - `/identity/handler/default.json`
+    - `/identity/handler/default.json`
-  - `/ldp/handler/default.json`.
+    - `/ldp/handler/default.json`.
 
 ## v1.1.0
+
 ### New features
-- The `ConstantConverter` can now filter on media type using the `enabledMediaRanges` and `disabledMediaRanges` options. That way, the server can be configured to bypass a default UI when accessing images or PDF documents. (https://github.com/solid/community-server/discussions/895, https://github.com/solid/community-server/pull/925)
+
+- The `ConstantConverter` can now filter on media type using the `enabledMediaRanges` and `disabledMediaRanges` options.
+  That way, the server can be configured to bypass a default UI when accessing images or PDF documents
+  (<https://github.com/solid/community-server/discussions/895>, <https://github.com/solid/community-server/pull/925>).
 
 ## v1.0.0
+
 First release of the Community Solid Server.

config/README.md

@@ -1,3 +1,5 @@
+# Configuration
+
 This folder contains several configurations that can be used to start up the server.
 All those configurations are created in the same way:
 features are enabled or disabled by choosing a specific option for every component.
@@ -8,13 +10,15 @@ Options are then chosen by importing 1 entry from every component subfolder.
 In case none of the available options have the exact feature configuration you want,
 it is always possible to not choose any of them and create your own custom version instead.
 
-# How to use
+## How to use
+
 The easiest way to create a new config is by creating a JSON-LD file
 that imports one option from every component subfolder
 (such as either `allow-all.json` or `webacl.json` from `ldp/authorization`).
 In case none of the available options suffice, there are 2 other ways to handle this:
 
-## Append to an existing config
+### Append to an existing config
+
 In case the options mostly suffice, but they just need to do a bit more,
 it might be possible to append to one of the solutions.
 
@@ -22,6 +26,7 @@ For example, in case all the existing metadata parsers can remain,
 but an additional one needs to be added,
 you could import `ldp/metadata-parser/default.json`
 and then add the following in your root config:
+
 ```json
     {
       "@id": "urn:solid-server:default:MetadataParser",
@@ -31,6 +36,7 @@ and then add the following in your root config:
       ]
     }
 ```
+
 This will add the new parser to the list of metadata parsers.
 The `@id` value is needed so Components.js knows which object to add the values to,
 and the `@type` is needed so it can interpret the other fields (`handlers` in this case).
@@ -38,13 +44,15 @@ and the `@type` is needed so it can interpret the other fields (`handlers` in th
 Note that generally it is only advised to append to ParallelHandlers or key/value maps.
 In case the order is important this can not be guaranteed over separate files.
 
-## Create a new option
+### Create a new option
+
 If a more drastic change is required,
 the solution is to not import anything from that folder but instead write your own.
 
 For example, in case you only want the slug parser but not any of the others,
 you would have to not import anything from `ldp/metadata-parser` folder,
 but instead have the following in your root config:
+
 ```json
     {
       "@id": "urn:solid-server:default:MetadataParser",
@@ -54,5 +62,6 @@ but instead have the following in your root config:
       ]
     }
 ```
+
 Don't forget that in some cases you would also have to copy some imports!
 The existing options can be used as inspiration.

config/app/README.md

@@ -1,20 +1,27 @@
 # App
+
 Options related to the server startup.
 
 ## Base
+
 This is the entry point to the main server setup.
-* *default*: The main application. This should only be changed/replaced 
+
+* *default*: The main application. This should only be changed/replaced
              if you want to start from a different kind of class.
 
 ## Init
+
 Contains a list of initializer that need to be run when starting the server.
+
 * *default*: The default setup. The ParallelHandler can be used to add custom Initializers.
 * *initialize-root*: Makes sure the root container has the necessary resources to function properly.
                      This is only relevant if setup is disabled but root container access is still required.
 * *initialize-prefilled-root*: Similar to `initialize-root` but adds some introductory resources to the root container.
 
 ## Setup
+
 Handles the setup page the first time the server is started.
+
 * *disabled*: Disables the setup page. Root container access will be impossible unless handled by the Init config above.
               Registration and pod creation is still possible if that feature is enabled.
 * *optional*: Setup is available at `/setup` but the server can already be used.
@@ -22,9 +29,11 @@ Handles the setup page the first time the server is started.
 * *required*: All requests will be redirected to the setup page until setup is completed.
 
 ## Variables
+
 Handles parsing CLI parameters and assigning values to Components.js variables.
 Some parts of the configuration contains variables that can be set as arguments on the command-line.
-That way, you don't have to edit the configuration files for small changes, 
+That way, you don't have to edit the configuration files for small changes,
 such as starting the server with a different hostname.
 Here, you can customize the mapping from CLI arguments into values for those variables.
+
 * *default*: Assigns CLI parameters for all variables defined in `/config/util/variables/default.json`

config/http/README.md

@@ -1,19 +1,26 @@
 # HTTP
+
 Options related to the base support of HTTP requests by the server.
 
 ## Handler
+
 Sets up all the handlers a request will potentially pass through.
+
 * *default*: The full setup, that is middleware + static files + IDP + LDP.
 * *simple*: A simpler setup in which the IDP is disabled.
 
 ## Middleware
+
 A set of handlers that will always be run on all requests to add some metadata
 and then pass the request along.
+
 * *no-websockets*: The default setup but without the websocket-related metadata.
 * *websockets*: The default setup with several handlers.
 
 ## Server-Factory
+
 The factory used to create the actual server object.
+
 * *no-websockets*: Only HTTP.
 * *websockets*: HTTP and websockets.
 * *https-no-websockets*: Only HTTPS. Adds 2 new CLI params to set the key/cert paths.
@@ -22,6 +29,8 @@ The factory used to create the actual server object.
   by adding the key/cert paths to the config itself.
 
 ## Static
+
 Support for static files that should be found at a specific path.
+
 * *default*: The default handler with a favicon and css for the IDP.
   New entries can easily be added for new files.

config/identity/README.md

@@ -1,8 +1,11 @@
 # Identity
+
 Options related to the Identity Provider.
 
 ## Access
+
 Determines how publicly accessible some IDP features are.
+
 * *public*: Everything is publicly accessible.
 * *restricted*: The IDP components use the same authorization scheme as the main LDP component.
   For example, if the server uses WebACL authorization and the registration endpoint is `/idp/register/`,
@@ -12,29 +15,39 @@ Determines how publicly accessible some IDP features are.
   So make sure to update those two containers so only the correct credentials have the correct rights.
 
 ## Email
+
 Necessary for sending e-mail when using IDP.
+
 * *default*: Disables e-mail functionality.
 * *example*: An example of what your e-mail configuration should look like.
   In that case you should not import anything from this folder
   but have the settings in your root config.
 
 ## Handler
+
 Contains everything needed for setting up the Identity Provider.
+
 * *default*: As of writing there is not much customization possible.
   This contains everything needed.
-  
+
 ## Ownership
+
 Which technique to use to determine if a requesting agent owns a WebID.
+
 * *token*: A token needs to added to the WebID to prove ownership.
 * *unsafe-no-check*: No verification is done, the agent is always believed.
 
 ## Pod
+
 What to use for pod creation.
+
 * *dynamic*: Every created pod has its own Components.js config for its ResourceStore,
   which can differ from the others.
 * *static*: All pod data is stored in separate containers in the same ResourceStore.
 
 ## Registration
+
 If users should be able to register on the server.
+
 * *enabled*: Enables registration.
 * *disabled*: Disables registration.

config/ldp/README.md

@@ -1,33 +1,46 @@
 # LDP
+
 Options related to the Linked Data Platform implementation.
 This is the core part of the Solid server.
 
 ## Authentication
+
 Covers how agents are identified.
+
 * *debug-auth-header*: Allows authentication headers such as `WebID http://test.com/card#me`
   to identify as that WebID without further checks.
 * *debug-test-agent*: Always assumes the agent is the set identifier.
 * *dpop-bearer*: Uses the default DPoP and Bearer identification.
 
 ## Authorization
+
 Covers how operations are authorized (or rejected).
+
 * *allow-all*: No authorization, everything is allowed.
 * *webacl*: Use the default Web Access Control.
 
 ## Handler
+
 Contains the default LDP handler that will handle most requests.
+
 * *default*: The default setup.
   Some identifiers seen here are defined by the other options found in this document.
 
 ## Metadata-Parser
+
 Contains a list of parsers that will be run on incoming requests to generate metadata.
+
 * *default*: Contains the default parsers. Can be added to when specific parsers are required.
 
 ## Metadata-Writer
+
 Contains a list of metadata writers that will be run on outgoing responses.
+
 * *default*: Contains the default writers. Can be added to when specific parsers are required.
 
 ## Modes
+
 Determines which modes are needed for requests,
 by default this is based on the used HTTP method.
+
 * *default*: Bases required modes on HTTP method.

config/storage/README.md

@@ -1,8 +1,11 @@
 # Storage
+
 Options related to how data and resources are stored.
 
 ## Backend
+
 The final part of the ResourceStore chain that handles data access.
+
 * *dynamic*: The routing store used here is needed when using dynamic pod creation.
 * *file*: Default setup with a file backend.
 * *global-quota-file*: File backend with a global quota over the entire server.
@@ -13,12 +16,16 @@ The final part of the ResourceStore chain that handles data access.
   Also updates the converting store so all incoming data is transformed into quads.
 
 ## Key-Value
+
 Used by certain classes for internal storage.
+
 * *memory*: Store everything in memory.
 * *resource-store*: Store everything in a specific container in the resource store.
 
 ## Middleware
+
 The chain of utility ResourceStores that needs to be passed through before reaching the backend stores.
 The final store in this chain takes the store from the stores/backend config as source.
-* *default*: Chains all the utility stores: 
+
+* *default*: Chains all the utility stores:
   Monitoring -> IndexRepresentation -> Locking -> Patching -> Converting

config/util/README.md

@@ -1,47 +1,62 @@
 # Util
+
 Various utility related options.
 
 ## Auxiliary
+
 Exports an object that contains a list of all auxiliary resources that need to be supported.
 In case you create a new auxiliary strategy you can just add it to this list.
+
 * *acl*: Default list with only support for acl auxiliary resources.
 * *no-acl*: An empty list which can be added to.
 
 ## Identifiers
+
 How identifiers should be interpreted.
 This is mostly relevant when creating pods and/or using a file-based backend.
+
 * *subdomain*: New pod identifier would be `http://alice.test.com/`.
   File path of `http://alice.test.com/foo` would be `/alice/foo`.
 * *suffix*: New pod identifier would be `http://test.com/alice`.
   Requests to subdomain identifiers would be rejected.
 
 ## Index
+
 This can be used to provide different behaviour for index files.
 This is mostly relevant for user interfaces.
+
 * *default*: No special support.
 * *example*: An example of how this could be configured.
   If this is needed the best solution is usually to not import anything here
   and have the index setup in the root config.
 
 ## Logging
+
 Which logger to use.
+
 * *no-logging*: Disables all logging.
 * *winston*: Uses the winston logger.
 
 ## Representation-conversion
+
 Used for converting from one content type to another when needed.
 When a new content type needs to be supported, this can be done by adding a corresponding converter
 to the ChainedConverter list.
+
 * *default*: The default conversion setup which supports most RDF formats.
 
 ## Resource-locker
+
 Which locking mechanism to use to for example prevent 2 write simultaneous write requests.
+
 * *debug-void*: No locking mechanism, does not prevent simultaneous read/writes.
 * *file*: Uses a file-system based locking mechanism (process-safe/thread-safe).
 * *memory*: Uses an in-memory locking mechanism.
 * *redis*: Uses a Redis store for locking that supports threadsafe read-write locking (process-safe/thread-safe).
 
 ## Variables
+
 Various variables used by other options.
 These can usually be set through CLI parameters.
+
 * *default*: The default list of variables.

documentation/markdown/README.md

@@ -24,26 +24,26 @@ This is a good way to get started with the server and its setup.
 If you want to know what is new in the latest version,
 you can check out the [release notes](https://github.com/CommunitySolidServer/CommunitySolidServer/blob/main/RELEASE_NOTES.md)
 for a high level overview and information on how to migrate your configuration to the next version.
-A list that includes all minor changes can be found in 
+A list that includes all minor changes can be found in
 the [changelog](https://github.com/CommunitySolidServer/CommunitySolidServer/blob/main/CHANGELOG.md)
 
 ## Using the server
 
- * [Basic example HTTP requests](usage/example-requests.md)
+* [Basic example HTTP requests](usage/example-requests.md)
- * [Editing the metadata of a resource](usage/metadata.md)
+* [Editing the metadata of a resource](usage/metadata.md)
- * [How to use the Identity Provider](usage/identity-provider.md)
+* [How to use the Identity Provider](usage/identity-provider.md)
- * [How to automate authentication](usage/client-credentials.md)
+* [How to automate authentication](usage/client-credentials.md)
- * [How to automatically seed pods on startup](usage/seeding-pods.md)
+* [How to automatically seed pods on startup](usage/seeding-pods.md)
 
 ## What the internals look like
 
- * [How the server uses dependency injection](architecture/dependency-injection.md)
+* [How the server uses dependency injection](architecture/dependency-injection.md)
- * [What the architecture looks like](architecture/overview.md)
+* [What the architecture looks like](architecture/overview.md)
- 
+
 ## Making changes
 
- * [How to make changes to the repository](contributing/making-changes.md)
+* [How to make changes to the repository](contributing/making-changes.md)
 
-For core developers with push access only: 
+For core developers with push access only:
 
- * [How to release a new version](contributing/release.md)
+* [How to release a new version](contributing/release.md)

documentation/markdown/architecture/core.md

@@ -4,6 +4,7 @@ There are several core building blocks used in many places of the server.
 These are described here.
 
 ## Handlers
+
 A very important building block that gets reused in many places is the `AsyncHandler`.
 The idea is that a handler has 2 important functions.
 `canHandle` determines if this class is capable of correctly handling the request,
@@ -33,6 +34,7 @@ and the `SequenceHandler` that runs all of them one after the other.
 Since multiple handlers are executed here, these only work for handlers that have no output.
 
 ## Streams
+
 Almost all data is handled in a streaming fashion.
 This allows us to work with very large resources without having to fully load them in memory,
 a client could be reading data that is being returned by the server while the server is still reading the file.

documentation/markdown/architecture/dependency-injection.md

@@ -6,13 +6,14 @@ to link all class instances together,
 and uses [Components-Generator.js](https://github.com/LinkedSoftwareDependencies/Components-Generator.js)
 to automatically generate the necessary description configurations of all classes.
 This framework allows us to configure our components in a JSON file.
-The advantage of this is that changing the configuration of components does not require any changes to the code, 
+The advantage of this is that changing the configuration of components does not require any changes to the code,
 as one can just change the default configuration file, or provide a custom configuration file.
 
 More information can be found in the Components.js [documentation](https://componentsjs.readthedocs.io/),
 but a summarized overview can be found below.
 
 ## Component files
+
 Components.js requires a component file for every class you might want to instantiate.
 Fortunately those get generated automatically by Components-Generator.js.
 Calling `npm run build` will call the generator and generate those JSON-LD files in the `dist` folder.
@@ -20,12 +21,14 @@ The generator uses the `index.ts`, so new classes always have to be added there
 or they will not get a component file.
 
 ## Configuration files
+
 Configuration files are how we tell Components.js which classes to instantiate and link together.
 All the community server configurations can be found in
 the [`config` folder](https://github.com/CommunitySolidServer/CommunitySolidServer/tree/main/config/).
 That folder also contains information about how different pre-defined configurations can be used.
 
-A single component in such a configuration file might look as follows: 
+A single component in such a configuration file might look as follows:
+
 ```json
 {
   "comment": "Storage used for account management.",
@@ -38,13 +41,16 @@ A single component in such a configuration file might look as follows:
 ```
 
 With the corresponding constructor of the `JsonResourceStorage` class:
+
 ```ts
 public constructor(source: ResourceStore, baseUrl: string, container: string)
 ```
 
 The important elements here are the following:
+
 * `"comment"`: _(optional)_ A description of this component.
-* `"@id"`: _(optional)_ A unique identifier of this component, which allows it to be used as parameter values in different places.
+* `"@id"`: _(optional)_ A unique identifier of this component, which allows it to be used as parameter values in
+    different places.
 * `"@type"`: The class name of the component. This must be a TypeScript class name that is exported via `index.ts`.
 
 As you can see from the constructor, the other fields are direct mappings from the constructor parameters.

documentation/markdown/architecture/features/cli.md

@@ -10,7 +10,7 @@ These then get converted into Components.js variables and are used to instantiat
 flowchart TD
   CliResolver("<strong>CliResolver</strong><br>CliResolver")
   CliResolver --> CliResolverArgs
-  
+
   subgraph CliResolverArgs[" "]
     CliExtractor("<strong>CliExtractor</strong><br>YargsCliExtractor")
     ShorthandResolver("<strong>ShorthandResolver</strong><br>CombinedShorthandResolver")
@@ -24,9 +24,9 @@ flowchart TD
   end
 ```
 
-The `CliResolver` (`urn:solid-server-app-setup:default:CliResolver`) is simply a way 
+The `CliResolver` (`urn:solid-server-app-setup:default:CliResolver`) is simply a way
-to combine both the `CliExtractor` (`urn:solid-server-app-setup:default:CliExtractor`) 
+to combine both the `CliExtractor` (`urn:solid-server-app-setup:default:CliExtractor`)
-and `ShorthandResolver` (`urn:solid-server-app-setup:default:ShorthandResolver`) 
+and `ShorthandResolver` (`urn:solid-server-app-setup:default:ShorthandResolver`)
 into a single object and has no other function.
 
 Which arguments are supported and which Components.js variables are generated
@@ -34,10 +34,12 @@ can depend on the configuration that is being used.
 For example, for an HTTPS server additional arguments will be needed to specify the necessary key/cert files.
 
 ## CliResolver
+
 The `CliResolver` converts the incoming string of arguments into a key/value object.
 By default, a `YargsCliExtractor` is used, which makes use of the `yargs` library and is configured similarly.
 
 ## ShorthandResolver
+
 The `ShorthandResolver` uses the key/value object that was generated above to generate Components.js variable bindings.
 A `CombinedShorthandResolver` combines the results of multiple `ShorthandExtractor`
 by mapping their values to specific variables.

documentation/markdown/architecture/features/http-handler.md

@@ -1,19 +1,21 @@
 # Handling HTTP requests
+
 The direction of the arrows was changed slightly here to make the graph readable.
+
 ```mermaid
 flowchart LR
   HttpHandler("<strong>HttpHandler</strong><br>SequenceHandler")
   HttpHandler --> HttpHandlerArgs
-  
+
   subgraph HttpHandlerArgs[" "]
     direction LR
     Middleware("<strong>Middleware</strong><br><i>HttpHandler</i>")
     WaterfallHandler("<br>WaterfallHandler")
   end
-  
+
   Middleware --> WaterfallHandler
   WaterfallHandler --> WaterfallHandlerArgs
-  
+
   subgraph WaterfallHandlerArgs[" "]
     direction TB
     StaticAssetHandler("<strong>StaticAssetHandler</strong><br>StaticAssetHandler")
@@ -23,7 +25,7 @@ flowchart LR
     IdentityProviderHttpHandler("<strong>IdentityProviderHttpHandler</strong><br><i>HttpHandler</i>")
     LdpHandler("<strong>LdpHandler</strong><br><i>HttpHandler</i>")
   end
-  
+
   StaticAssetHandler --> SetupHandler
   SetupHandler --> OidcHandler
   OidcHandler --> AuthResourceHttpHandler
@@ -40,13 +42,15 @@ to find the first handler that understands the request,
 with the `LdpHandler` at the bottom being the catch-all default.
 
 ## StaticAssetHandler
+
 The `urn:solid-server:default:StaticAssetHandler` matches exact URLs to static assets which require no further logic.
-An example of this is the favicon, where the `/favicon.ico` URL 
+An example of this is the favicon, where the `/favicon.ico` URL
 is directed to the favicon file at `/templates/images/favicon.ico`.
 It can also map entire folders to a specific path, such as `/.well-known/css/styles/` which contains all stylesheets.
 
 ## SetupHandler
-The `urn:solid-server:default:SetupHandler` is responsible 
+
+The `urn:solid-server:default:SetupHandler` is responsible
 for redirecting all requests to `/setup` until setup is finished,
 thereby ensuring that setup needs to be finished before anything else can be done on the server,
 and handling the actual setup request that is sent to `/setup`.
@@ -56,12 +60,14 @@ If the server is configured to not have setup enabled,
 the corresponding identifier will point to a handler that always rejects all requests.
 
 ## OidcHandler
+
 The `urn:solid-server:default:OidcHandler` handles all requests related
 to the Solid-OIDC [specification](https://solid.github.io/solid-oidc/).
 The OIDC component is configured to work on the `/.oidc/` subpath,
 so this handler catches all those requests and sends them to the internal OIDC library that is used.
 
 ## AuthResourceHttpHandler
+
 The `urn:solid-server:default:AuthResourceHttpHandler` is identical
 to the `urn:solid-server:default:LdpHandler` which will be discussed below,
 but only handles resources relevant for authorization.
@@ -75,12 +81,14 @@ to allow authorization on the following handler(s).
 More on this can be found in the [identity provider](../../../usage/identity-provider/#access) documentation
 
 ## IdentityProviderHttpHandler
+
 The `urn:solid-server:default:IdentityProviderHttpHandler` handles everything
 related to our custom identity provider API, such as registering, logging in, returning the relevant HTML pages, etc.
 All these requests are identified by being on the `/idp/` subpath.
 More information on the API can be found in the [identity provider](../../../usage/identity-provider) documentation
 
 ## LdpHandler
+
 Once a request reaches the `urn:solid-server:default:LdpHandler`,
 the server assumes this is a standard Solid request according to the Solid protocol.
 A detailed description of what happens then can be found [here](protocol/overview.md)

documentation/markdown/architecture/features/initialization.md

@@ -6,11 +6,12 @@ Similarly, when stopping the server several Finalizers trigger to clean up where
 although the latter only happens when starting the server through code.
 
 ## App
+
 ```mermaid
 flowchart TD
   App("<strong>App</strong><br>App")
   App --> AppArgs
-  
+
   subgraph AppArgs[" "]
     Initializer("<strong>Initializer</strong><br><i>Initializer</i>")
     AppFinalizer("<strong>Finalizer</strong><br><i>Finalizer</i>")
@@ -24,18 +25,19 @@ It's only function is to contain an `Initializer` and `Finalizer`
 which get called by calling `start`/`stop` respectively.
 
 ## Initializer
+
 ```mermaid
 flowchart TD
   Initializer("<strong>Initializer</strong><br>SequenceHandler")
   Initializer --> InitializerArgs
-  
+
   subgraph InitializerArgs[" "]
     direction LR
     LoggerInitializer("<strong>LoggerInitializer</strong><br>LoggerInitializer")
     PrimaryInitializer("<strong>PrimaryInitializer</strong><br>ProcessHandler")
     WorkerInitializer("<strong>WorkerInitializer</strong><br>ProcessHandler")
   end
-  
+
   LoggerInitializer --> PrimaryInitializer
   PrimaryInitializer --> WorkerInitializer
 ```
@@ -49,26 +51,28 @@ Although if your server setup is single-threaded, which is the default,
 there is no relevant difference between those two.
 
 ### PrimaryInitializer
+
 ```mermaid
 flowchart TD
   PrimaryInitializer("<strong>PrimaryInitializer</strong><br>ProcessHandler")
   PrimaryInitializer --> PrimarySequenceInitializer("<strong>PrimarySequenceInitializer</strong><br>SequenceHandler")
   PrimarySequenceInitializer --> PrimarySequenceInitializerArgs
-  
+
   subgraph PrimarySequenceInitializerArgs[" "]
     direction LR
     CleanupInitializer("<strong>CleanupInitializer</strong><br>SequenceHandler")
     PrimaryParallelInitializer("<strong>PrimaryParallelInitializer</strong><br>ParallelHandler")
     WorkerManager("<strong>WorkerManager</strong><br>WorkerManager")
   end
-  
+
   CleanupInitializer --> PrimaryParallelInitializer
   PrimaryParallelInitializer --> WorkerManager
 ```
+
 The above is a simplification of all the initializers that are present in the `PrimaryInitializer`
 as there are several smaller initializers that also trigger but are less relevant here.
 
-The `CleanupInitializer` is an initializer that cleans up anything 
+The `CleanupInitializer` is an initializer that cleans up anything
 that might have remained from a previous server start
 and could impact behaviour.
 Relevant components in other parts of the configuration are responsible for adding themselves to this array if needed.
@@ -80,35 +84,39 @@ This makes it easier for users to add initializers by being able to append to it
 The `WorkerManager` is responsible for setting up the worker threads, if any.
 
 ### WorkerInitializer
+
 ```mermaid
 flowchart TD
   WorkerInitializer("<strong>WorkerInitializer</strong><br>ProcessHandler")
   WorkerInitializer --> WorkerSequenceInitializer("<strong>WorkerSequenceInitializer</strong><br>SequenceHandler")
   WorkerSequenceInitializer --> WorkerSequenceInitializerArgs
-  
+
   subgraph WorkerSequenceInitializerArgs[" "]
     direction LR
     WorkerParallelInitializer("<strong>WorkerParallelInitializer</strong><br>ParallelHandler")
     ServerInitializer("<strong>ServerInitializer</strong><br>ServerInitializer")
   end
-  
+
   WorkerParallelInitializer --> ServerInitializer
 ```
+
 The `WorkerInitializer` is quite similar to the `PrimaryInitializer` but triggers once per worker thread.
 Like the `PrimaryParallelInitializer`, the `WorkerParallelInitializer` can be used
 to add any custom initializers that need to run.
 
 ### ServerInitializer
+
 The `ServerInitializer` is the initializer that finally starts up the server by listening to the relevant port,
 once all the initialization described above is finished.
 This is an example of a component that differs based on some of the choices made during configuration.
+
 ```mermaid
 flowchart TD
   ServerInitializer("<strong>ServerInitializer</strong><br>ServerInitializer")
   ServerInitializer --> WebSocketServerFactory("<strong>ServerFactory</strong><br>WebSocketServerFactory")
   WebSocketServerFactory --> BaseHttpServerFactory("<br>BaseHttpServerFactory")
   BaseHttpServerFactory --> HttpHandler("<strong>HttpHandler</strong><br><i>HttpHandler</i>")
-  
+
   ServerInitializer2("<strong>ServerInitializer</strong><br>ServerInitializer")
   ServerInitializer2 ---> BaseHttpServerFactory2("<strong>ServerFactory</strong><br>BaseHttpServerFactory")
   BaseHttpServerFactory2 --> HttpHandler2("<strong>HttpHandler</strong><br><i>HttpHandler</i>")

documentation/markdown/architecture/features/protocol/authorization.md

@@ -4,7 +4,7 @@
 flowchart TD
   AuthorizingHttpHandler("<br>AuthorizingHttpHandler")
   AuthorizingHttpHandler --> AuthorizingHttpHandlerArgs
-  
+
   subgraph AuthorizingHttpHandlerArgs[" "]
     CredentialsExtractor("<strong>CredentialsExtractor</strong><br><i>CredentialsExtractor</i>")
     ModesExtractor("<strong>ModesExtractor</strong><br><i>ModesExtractor</i>")
@@ -25,6 +25,7 @@ It goes through the following steps:
 5. If the request is allowed, call the `OperationHttpHandler`, otherwise throw an error.
 
 ## Authentication
+
 There are multiple `CredentialsExtractor`s that each determine identity in a different way.
 Potentially multiple extractors can apply,
 making a requesting agent have multiple credentials.
@@ -35,12 +36,12 @@ The diagram below shows the default configuration if authentication is enabled.
 flowchart TD
   CredentialsExtractor("<strong>CredentialsExtractor</strong><br>UnionCredentialsExtractor")
   CredentialsExtractor --> CredentialsExtractorArgs
-  
+
   subgraph CredentialsExtractorArgs[" "]
     WaterfallHandler("<br>WaterfallHandler")
     PublicCredentialsExtractor("<br>PublicCredentialsExtractor")
   end
-  
+
   WaterfallHandler --> WaterfallHandlerArgs
   subgraph WaterfallHandlerArgs[" "]
     direction LR
@@ -48,8 +49,8 @@ flowchart TD
   end
 ```
 
-Both of the WebID extractors make use of 
+Both of the WebID extractors make use of
-the (`access-token-verifier`)[https://github.com/CommunitySolidServer/access-token-verifier] library
+the [`access-token-verifier`](https://github.com/CommunitySolidServer/access-token-verifier) library
 to parse incoming tokens based on the [Solid-OIDC specification](https://solid.github.io/solid-oidc/).
 Besides those there are always the public credentials, which everyone has.
 All these credentials then get combined into a single union object.
@@ -61,6 +62,7 @@ There are also debug configuration options available that can be used to simulat
 These can be enabled as different options through the `config/ldp/authentication` imports.
 
 ## Modes extraction
+
 Access modes are a predefined list of `read`, `write`, `append`, `create` and `delete`.
 The `ModesExtractor` determine which modes will be necessary and for which resources,
 based on the request contents.
@@ -69,9 +71,9 @@ based on the request contents.
 flowchart TD
   ModesExtractor("<strong>ModesExtractor</strong><br>IntermediateCreateExtractor")
   ModesExtractor --> HttpModesExtractor("<strong>HttpModesExtractor</strong><br>WaterfallHandler")
-  
+
   HttpModesExtractor --> HttpModesExtractorArgs
-  
+
   subgraph HttpModesExtractorArgs[" "]
     direction LR
     PatchModesExtractor("<strong>PatchModesExtractor</strong><br><i>ModesExtractor</i>") --> MethodModesExtractor("<br>MethodModesExtractor")
@@ -79,7 +81,8 @@ flowchart TD
 ```
 
 The `IntermediateCreateExtractor` is responsible if requests try to create intermediate containers with a single request.
-E.g., a PUT request to `/foo/bar/baz` should create both the `/foo/` and `/foo/bar/` containers in case they do not exist yet.
+E.g., a PUT request to `/foo/bar/baz` should create both the `/foo/` and `/foo/bar/` containers in case they do not
+exist yet.
 This extractor makes sure that `create` permissions are also checked on those containers.
 
 Modes can usually be determined based on just the HTTP methods,
@@ -90,7 +93,7 @@ The only exception are PATCH requests,
 where the necessary modes depend on the body and the PATCH type.
 
 ```mermaid
-flowchart TD  
+flowchart TD
   PatchModesExtractor("<strong>PatchModesExtractor</strong><br>WaterfallHandler") --> PatchModesExtractorArgs
   subgraph PatchModesExtractorArgs[" "]
     N3PatchModesExtractor("<br>N3PatchModesExtractor")
@@ -102,6 +105,7 @@ The server supports both N3 Patch and SPARQL Update PATCH requests.
 In both cases it will parse the bodies to determine what the impact would be of the request and what modes it requires.
 
 ## Permission reading
+
 `PermissionReaders` take the input of the above to determine which permissions are available for which credentials.
 The modes from the previous step are not yet needed,
 but can be used as optimization as we only need to know if we have permission on those modes.
@@ -111,17 +115,17 @@ In case authorization is disabled by changing the authorization import to `confi
 this diagram is just a class that always returns all permissions.
 
 ```mermaid
-flowchart TD  
+flowchart TD
   PermissionReader("<strong>PermissionReader</strong><br>AuxiliaryReader")
   PermissionReader --> UnionPermissionReader("<br>UnionPermissionReader")
   UnionPermissionReader --> UnionPermissionReaderArgs
-  
+
   subgraph UnionPermissionReaderArgs[" "]
     PathBasedReader("<strong>PathBasedReader</strong><br>PathBasedReader")
     OwnerPermissionReader("<strong>OwnerPermissionReader</strong><br>OwnerPermissionReader")
     WrappedWebAclReader("<strong>WrappedWebAclReader</strong><br>ParentContainerReader")
   end
-  
+
   WrappedWebAclReader --> WebAclAuxiliaryReader("<strong>WebAclAuxiliaryReader</strong><br>WebAclAuxiliaryReader")
   WebAclAuxiliaryReader --> WebAclReader("<strong>WebAclReader</strong><br>WebAclReader")
 ```
@@ -136,7 +140,7 @@ If one reader rejects a specific mode and another allows it, the rejection takes
 The `PathBasedReader` rejects all permissions for certain paths.
 This is used to prevent access to the internal data of the server.
 
-The `OwnerPermissionReader` makes sure owners always have control access 
+The `OwnerPermissionReader` makes sure owners always have control access
 to the [pods they created on the server](../../../../usage/identity-provider/#pod).
 Users will always be able to modify the ACL resources in their pod,
 even if they accidentally removed their own access.
@@ -150,12 +154,13 @@ In case the target is an ACL resource, `control` permissions need to be checked,
 no matter what mode was generated by the `ModesExtractor`.
 The `WebAclAuxiliaryReader` makes sure this conversion happens.
 
-Finally, the `WebAclReader` implements 
+Finally, the `WebAclReader` implements
 the [efffective ACL resource algorithm](https://solidproject.org/TR/2021/wac-20210711#effective-acl-resource)
 and returns the permissions it finds in that resource.
 In case no ACL resource is found this indicates a configuration error and no permissions will be granted.
 
 ## Authorization
+
 All the results of the previous steps then get combined in the `PermissionBasedAuthorizer` to either allow or reject a request.
 If no permissions are found for a requested mode,
 or they are explicitly forbidden,

documentation/markdown/architecture/features/protocol/overview.md

@@ -1,4 +1,5 @@
 # Solid protocol
+
 The `LdpHandler`, named as a reference to the Linked Data Platform specification,
 chains several handlers together, each with their own specific purpose, to fully resolve the HTTP request.
 It specifically handles Solid requests as described

documentation/markdown/architecture/features/protocol/parsing.md

@@ -1,9 +1,10 @@
 # Parsing and responding to HTTP requests
+
 ```mermaid
 flowchart TD
   ParsingHttphandler("<br>ParsingHttphandler")
   ParsingHttphandler --> ParsingHttphandlerArgs
-  
+
   subgraph ParsingHttphandlerArgs[" "]
     RequestParser("<strong>RequestParser</strong><br>BasicRequestParser")
     AuthorizingHttpHandler("<strong></strong><br>AuthorizingHttpHandler")
@@ -17,11 +18,12 @@ It follows these 3 steps:
 
 1. Use the `RequestParser` to convert the incoming data into an `Operation`.
 2. Send the `Operation` to the `AuthorizingHttpHandler` to receive either a `Representation` if the operation was a success,
-   or an `Error` in case something went wrong.
+    or an `Error` in case something went wrong.
-   * In case of an error the `ErrorHandler` will convert the `Error` into a `ResponseDescription`.
+    * In case of an error the `ErrorHandler` will convert the `Error` into a `ResponseDescription`.
 3. Use the `ResponseWriter` to output the `ResponseDescription` as an HTTP response.
 
 ## Parsing the request
+
 ```mermaid
 flowchart TD
   RequestParser("<strong>RequestParser</strong><br>BasicRequestParser") --> RequestParserArgs
@@ -32,12 +34,14 @@ flowchart TD
     BodyParser("<br><i>Bodyparser</i>")
     Conditions("<br>BasicConditionsParser")
   end
-  
+
   OriginalUrlExtractor --> IdentifierStrategy("<strong>IdentifierStrategy</strong><br><i>IdentifierStrategy</i>")
 ```
+
 The `BasicRequestParser` is mostly an aggregator of multiple smaller parsers that each handle a very specific part.
 
 ### URL
+
 This is a single class, the `OriginalUrlExtractor`, but fulfills the very important role
 of making sure input URLs are handled consistently.
 
@@ -53,14 +57,16 @@ This can differ depending on if the server uses subdomains or not.
 The resulting identifier will be stored in the `target` field of an `Operation` object.
 
 ### Preferences
+
 The `AcceptPreferenceParser` parses the `Accept` header and all the relevant `Accept-*` headers.
 These will all be put into the `preferences` field of an `Operation` object.
 These will later be used to handle the content negotiation.
 
-For example, when sending an `Accept: text/turtle; q=0.9` header, 
+For example, when sending an `Accept: text/turtle; q=0.9` header,
 this wil result in the preferences object `{ type: { 'text/turtle': 0.9 } }`.
 
 ### Headers
+
 Several other headers can have relevant metadata,
 such as the `Content-Type` header,
 or the `Link: <http://www.w3.org/ns/ldp#Container>; rel="type"` header
@@ -73,6 +79,7 @@ The default `MetadataParser` is a `ParallelHandler` that contains several smalle
 each looking at a specific header.
 
 ### Body
+
 In case of most requests, the input data stream is used directly in the `body` field of the `Operation`,
 with a few minor checks to make sure the HTTP specification is being followed.
 
@@ -82,19 +89,21 @@ into a JavaScript object containing all the necessary information to execute suc
 Several validation checks will already take place there as well.
 
 ### Conditions
+
 The `BasicConditionsParser` parses everything related to conditions headers,
 such as `if-none-match` or `if-modified-since`,
 and stores the relevant information in the `conditions` field of the `Operation`.
 These will later be used to make sure the request should be aborted or not.
 
 ## Sending the response
+
 In case a request is successful, the `AuthorizingHttpHandler` will return a `ResponseDescription`,
 and if not it will throw an error.
 
 In case an error gets thrown, this will be caught by the `ErrorHandler` and converted into a `ResponseDescription`.
 The request preferences will be used to make sure the serialization is one that is preferred.
 
-Either way we will have a `ResponseDescription`, 
+Either way we will have a `ResponseDescription`,
 which will be sent to the `BasicResponseWriter` to convert into output headers, data and a status code.
 
 To convert the metadata into headers, it uses a `MetadataWriter`,

documentation/markdown/architecture/features/protocol/resource-store.md

@@ -1,11 +1,12 @@
 # Resource store
+
 The interface of a `ResourceStore` is mostly a 1-to-1 mapping of the HTTP methods:
 
- * GET: `getRepresentation`
+* GET: `getRepresentation`
- * PUT: `setRepresentation`
+* PUT: `setRepresentation`
- * POST: `addResource`
+* POST: `addResource`
- * DELETE: `deleteResource`
+* DELETE: `deleteResource`
- * PATCH: `modifyResource`
+* PATCH: `modifyResource`
 
 The corresponding `OperationHandler` of the relevant method
 is responsible for calling the correct `ResourceStore` function.
@@ -14,36 +15,41 @@ In practice, the community server has multiple resource stores chained together,
 each handling a specific part of the request and then calling the next store in the chain.
 The default configurations come with the following stores:
 
- 1. `MonitoringStore`
+1. `MonitoringStore`
- 2. `IndexRepresentationStore`
+2. `IndexRepresentationStore`
- 3. `LockingResourceStore`
+3. `LockingResourceStore`
- 4. `PatchingStore`
+4. `PatchingStore`
- 5. `RepresentationConvertingStore`
+5. `RepresentationConvertingStore`
- 6. `DataAccessorBasedStore`
+6. `DataAccessorBasedStore`
 
 This chain can be seen in the configuration part in `config/storage/middleware/default.json`
 and all the entries in `config/storage/backend`.
 
 ## MonitoringStore
+
 This store emits the events that are necessary to emit notifications when resources change.
 
 There are 4 different events that can be emitted:
-- `this.emit('changed', identifier, activity)`: is emitted for every resource that was changed/effected by a call to the store.
+
-  With activity being undefined or one of the available ActivityStream terms.
+* `this.emit('changed', identifier, activity)`: is emitted for every resource that was changed/effected by a
-- `this.emit(AS.Create, identifier)`: is emitted for every resource that was created by the call to the store.
+    call to the store.
-- `this.emit(AS.Update, identifier)`: is emitted for every resource that was updated by the call to the store.
+    With activity being undefined or one of the available ActivityStream terms.
-- `this.emit(AS.Delete, identifier)`: is emitted for every resource that was deleted by the call to the store.
+* `this.emit(AS.Create, identifier)`: is emitted for every resource that was created by the call to the store.
+* `this.emit(AS.Update, identifier)`: is emitted for every resource that was updated by the call to the store.
+* `this.emit(AS.Delete, identifier)`: is emitted for every resource that was deleted by the call to the store.
 
 A `changed` event will always be emitted if a resource was changed.
-If the correct metadata was set by the source `ResourceStore`, an additional field will be sent along indicating the type of change,
+If the correct metadata was set by the source `ResourceStore`, an additional field will be sent along indicating the
-and an additional corresponding event will be emitted, depending on what the change is.
+type of change, and an additional corresponding event will be emitted, depending on what the change is.
 
 ## IndexRepresentationStore
+
 When doing a GET request on a container `/container/`,
 this container returns the contents of `/container/index.html` instead if HTML is the preferred response type.
 All these values are the defaults and can be configured for other resources and media types.
 
 ## LockingResourceStore
+
 To prevent data corruption, the server locks resources when being targeted by a request.
 Locks are only released when an operation is completely finished,
 in the case of read operations this means the entire data stream is read,
@@ -53,6 +59,7 @@ This allows simultaneous read requests on the same resource,
 but only while no write request is in progress.
 
 ## PatchingStore
+
 PATCH operations in Solid apply certain transformations on the target resource,
 which makes them more complicated than only reading or writing data since it involves both.
 The `PatchingStore` provides a generic solution for backends that do not implement the `modifyResource` function
@@ -63,6 +70,7 @@ apply the transformation on that data,
 and then PUT it back to the store.
 
 ## RepresentationConvertingStore
+
 This store handles everything related to content negotiation.
 In case the resulting data of a GET request does not match the preferences of a request,
 it will be converted here.
@@ -71,14 +79,13 @@ the SPARQL backend only accepts triples for example,
 that is also handled here
 
 ## DataAccessorBasedStore
+
 Large parts of the requirements of the Solid protocol specification are resolved by the `DataAccessorBasedStore`:
-POST only working on containers, 
+POST only working on containers, DELETE not working on non-empty containers,
-DELETE not working on non-empty containers, 
 generating `ldp:contains` triples for containers, etc.
 Most of this behaviour is independent of how the data is stored which is why it can be generalized here.
 The store's name comes from the fact that it makes use of `DataAccessor`s to handle the read/write of resources.
 A `DataAccessor` is a simple interface that only focuses on handling the data.
 It does not concern itself with any of the necessary Solid checks as it assumes those have already been made.
-This means that if a storage method needs to be supported,
+This means that if a storage method needs to be supported, only a new `DataAccessor` needs to be made,
-only a new `DataAccessor` needs to be made,
 after which it can be plugged into the rest of the server.

documentation/markdown/architecture/overview.md

@@ -1,6 +1,6 @@
 # Architecture overview
 
-The initial architecture document the project was started from can be found 
+The initial architecture document the project was started from can be found
 [here](https://rubenverborgh.github.io/solid-server-architecture/solid-architecture-v1-3-0.pdf).
 Many things have been added since the original inception of the project,
 but the core ideas within that document are still valid.
@@ -26,7 +26,7 @@ We will use an example below to explain the formatting used throughout the archi
 flowchart TD
   LdpHandler("<strong>LdpHandler</strong><br>ParsingHttphandler")
   LdpHandler --> LdpHandlerArgs
-  
+
   subgraph LdpHandlerArgs[" "]
     RequestParser("<strong>RequestParser</strong><br>BasicRequestParser")
     Auth("<br>AuthorizingHttpHandler")
@@ -38,14 +38,14 @@ flowchart TD
 Below is a summary of how to interpret such diagrams:
 
 * Rounded red box: component instantiated in the Components.js [configuration](dependency-injection.md).
-  * First line: 
+    * First line:
-    * **Bold text**: shorthand of the instance identifier. In case the full URI is not specified,
+        * **Bold text**: shorthand of the instance identifier. In case the full URI is not specified,
-      it can usually be found by prepending `urn:solid-server:default:` to the shorthand identifier.
+            it can usually be found by prepending `urn:solid-server:default:` to the shorthand identifier.
-    * (empty): this instance has no identifier and is defined in the same place as its parent.
+        * (empty): this instance has no identifier and is defined in the same place as its parent.
-  * Second line: 
+    * Second line:
-    * Regular text: The class of this instance.
+        * Regular text: The class of this instance.
-    * _Italic text_: The interface of this instance. 
+        * _Italic text_: The interface of this instance.
-      Will be used if the actual class is not relevant for the explanation or can differ.
+            Will be used if the actual class is not relevant for the explanation or can differ.
 * Square grey box: the parameters of the linked instance.
 * Arrow: links an instance to its parameters. Can also be used to indicate the order of parameters if relevant.
 
@@ -53,7 +53,8 @@ For example, in the above, **LdpHandler** is a shorthand for the actual identifi
 and is an instance of `ParsingHttpHandler`. It has 4 parameters,
 one of which has no identifier but is an instance of `AuthorizingHttpHandler`.
 
-# Features
+## Features
+
 Below are the sections that go deeper into the features of the server and how those work.
 
 * [How Command Line Arguments are parsed and used](features/cli.md)

documentation/markdown/contributing/making-changes.md

@@ -1,25 +1,26 @@
 # Pull requests
+
 The community server is fully written in [Typescript](https://www.typescriptlang.org/docs/home.html).
 
 All changes should be done through
-[pull requests](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork). 
+[pull requests](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork).
 
 We recommend first discussing a possible solution in the relevant issue
 to reduce the amount of changes that will be requested.
 
 In case any of your changes are breaking, make sure you target the next major branch (`versions/x.0.0`)
 instead of the main branch. Breaking changes include: changing interface/class signatures,
-potentially breaking external custom configurations, 
+potentially breaking external custom configurations,
 and breaking how internal data is stored.
 In case of doubt you probably want to target the next major branch.
 
 We make use of [Conventional Commits](https://www.conventionalcommits.org).
 
-Don't forget to update the [release notes](https://github.com/CommunitySolidServer/CommunitySolidServer/blob/main/RELEASE_NOTES.md) 
+Don't forget to update the [release notes](https://github.com/CommunitySolidServer/CommunitySolidServer/blob/main/RELEASE_NOTES.md)
 when adding new major features.
 Also update any relevant documentation in case this is needed.
 
-When making changes to a pull request, 
+When making changes to a pull request,
 we prefer to update the existing commits with a rebase instead of appending new commits,
 this way the PR can be rebased directly onto the target branch
 instead of needing to be squashed.
@@ -28,6 +29,6 @@ There are strict requirements from the linter and the test coverage before a PR
 These are configured to run automatically when trying to commit to git.
 Although there are no tests for it (yet), we strongly advice documenting with [TSdoc](https://github.com/microsoft/tsdoc).
 
-If a list of entries is alphabetically sorted, 
+If a list of entries is alphabetically sorted,
 such as [index.ts](https://github.com/CommunitySolidServer/CommunitySolidServer/blob/main/src/index.ts),
 make sure it stays that way.

documentation/markdown/contributing/release.md

@@ -12,12 +12,16 @@ Steps to follow:
     * None of the above has to be blocking per se, but should be noted in the release notes if relevant.
 * Verify that the `RELEASE_NOTES.md` are correct.
 * `npm run release -- -r major`
-    * Automatically updates Components.js references to the new version. Committed with `chore(release): Update configs to vx.0.0`.
+    * Automatically updates Components.js references to the new version.
-    * Updates the `package.json`, and generates the new entries in `CHANGELOG.md`. Commited with `chore(release): Release version vx.0.0 of the npm package`
+      Committed with `chore(release): Update configs to vx.0.0`.
-    * Optionally run `npx commit-and-tag-version -r major --dry-run` to preview the commands that will be run and the changes to `CHANGELOG.md`.
+    * Updates the `package.json`, and generates the new entries in `CHANGELOG.md`.
+      Commited with `chore(release): Release version vx.0.0 of the npm package`
+    * Optionally run `npx commit-and-tag-version -r major --dry-run` to preview the commands that will be run
+      and the changes to `CHANGELOG.md`.
 * The `postrelease` script will now prompt you to manually edit the `CHANGELOG.md`.
     * All entries are added in separate sections of the new release according to their commit prefixes.
-    * Re-organize the entries accordingly, referencing previous releases. Most of the entries in Chores and Documentation can be removed.
+    * Re-organize the entries accordingly, referencing previous releases. Most of the entries in Chores and
+      Documentation can be removed.
     * Press any key in your terminal when your changes are ready.
     * The `postrelease` script will amend the release commit, create an annotated tag and push changes to origin.
 * Merge `versions/x.0.0` into `main` and push.

documentation/markdown/usage/client-credentials.md

@@ -11,7 +11,7 @@ This is a temporary solution until the server has more advanced account manageme
 after which this API will change.
 
 Below is example code of how to make use of these tokens.
-It makes use of several utility functions from the 
+It makes use of several utility functions from the
 [Solid Authentication Client](https://github.com/inrupt/solid-client-authn-js).
 Note that the code below uses top-level `await`, which not all JavaScript engines support,
 so this should all be contained in an `async` function.
@@ -72,7 +72,7 @@ const response = await fetch(tokenUrl, {
 });
 
 // This is the Access token that will be used to do an authenticated request to the server.
-// The JSON also contains an "expires_in" field in seconds, 
+// The JSON also contains an "expires_in" field in seconds,
 // which you can use to know when you need request a new Access token.
 const { access_token: accessToken } = await response.json();
 ```

documentation/markdown/usage/example-requests.md

@@ -1,8 +1,9 @@
-## Interacting with the server
+# Interacting with the server
 
-### `PUT`: Creating resources for a given URL
+## `PUT`: Creating resources for a given URL
 
 Create a plain text file:
+
 ```shell
 curl -X PUT -H "Content-Type: text/plain" \
   -d "abc" \
@@ -10,15 +11,17 @@ curl -X PUT -H "Content-Type: text/plain" \
 ```
 
 Create a turtle file:
+
 ```shell
 curl -X PUT -H "Content-Type: text/turtle" \
   -d "<ex:s> <ex:p> <ex:o>." \
   http://localhost:3000/myfile.ttl
 ```
 
-### `POST`: Creating resources at a generated URL
+## `POST`: Creating resources at a generated URL
 
 Create a plain text file:
+
 ```shell
 curl -X POST -H "Content-Type: text/plain" \
   -d "abc" \
@@ -26,6 +29,7 @@ curl -X POST -H "Content-Type: text/plain" \
 ```
 
 Create a turtle file:
+
 ```shell
 curl -X POST -H "Content-Type: text/turtle" \
   -d "<ex:s> <ex:p> <ex:o>." \
@@ -34,33 +38,36 @@ curl -X POST -H "Content-Type: text/turtle" \
 
 The response's `Location` header will contain the URL of the created resource.
 
-### `GET`: Retrieving resources
+## `GET`: Retrieving resources
 
 Retrieve a plain text file:
+
 ```shell
 curl -H "Accept: text/plain" \
   http://localhost:3000/myfile.txt
 ```
 
 Retrieve a turtle file:
+
 ```shell
 curl -H "Accept: text/turtle" \
   http://localhost:3000/myfile.ttl
 ```
 
 Retrieve a turtle file in a different serialization:
+
 ```shell
 curl -H "Accept: application/ld+json" \
   http://localhost:3000/myfile.ttl
 ```
 
-### `DELETE`: Deleting resources
+## `DELETE`: Deleting resources
 
 ```shell
 curl -X DELETE http://localhost:3000/myfile.txt
 ```
 
-### `PATCH`: Modifying resources
+## `PATCH`: Modifying resources
 
 Modify a resource using [N3 Patch](https://solidproject.org/TR/protocol#n3-patch):
 
@@ -78,16 +85,15 @@ curl -X PATCH -H "Content-Type: application/sparql-update" \
   http://localhost:3000/myfile.ttl
 ```
 
-### `HEAD`: Retrieve resources headers
+## `HEAD`: Retrieve resources headers
 
 ```shell
 curl -I -H "Accept: text/plain" \
   http://localhost:3000/myfile.txt
 ```
 
-### `OPTIONS`: Retrieve resources communication options
+## `OPTIONS`: Retrieve resources communication options
 
 ```shell
 curl -X OPTIONS -i http://localhost:3000/myfile.txt
 ```
-

documentation/markdown/usage/identity-provider.md

@@ -4,22 +4,24 @@ Besides implementing the [Solid protocol](https://solidproject.org/TR/protocol),
 the community server can also be an Identity Provider (IDP), officially known as an OpenID Provider (OP),
 following the [Solid OIDC spec](https://solid.github.io/solid-oidc/) as much as possible.
 
-It is recommended to use the latest version 
+It is recommended to use the latest version
 of the [Solid authentication client](https://github.com/inrupt/solid-client-authn-js)
 to interact with the server.
 
 The links here assume the server is hosted at `http://localhost:3000/`.
 
 ## Registering an account
+
 To register an account, you can go to `http://localhost:3000/idp/register/` if this feature is enabled,
 which it is on all configurations we provide.
 Currently our registration page ties 3 features together on the same page:
 
- * Creating an account on the server.
+* Creating an account on the server.
- * Creating or linking a WebID to your account.
+* Creating or linking a WebID to your account.
- * Creating a pod on the server.
+* Creating a pod on the server.
 
 ### Account
+
 To create an account you need to provide an email address and password.
 The password will be salted and hashed before being stored.
 As of now, the account is only used to log in and identify yourself to the IDP
@@ -27,12 +29,13 @@ when you want to do an authenticated request,
 but in future the plan is to also use this for account/pod management.
 
 ### WebID
+
 We require each account to have a corresponding WebID.
 You can either let the server create a WebID for you in a pod,
 which will also need to be created then,
 or you can link an already existing WebID you have on an external server.
 
-In case you try to link your own WebID, you can choose if you want to be able 
+In case you try to link your own WebID, you can choose if you want to be able
 to use this server as your IDP for this WebID.
 If not, you can still create a pod,
 but you will not be able to direct the authentication client to this server to identify yourself.
@@ -47,6 +50,7 @@ that you have to add an additional triple to your WebID if you want to use the s
 All of the above is automated if you create the WebID on the server itself.
 
 ### Pod
+
 To create a pod you simply have to fill in the name you want your pod to have.
 This will then be used to generate the full URL of your pod.
 For example, if you choose the name `test`,
@@ -54,11 +58,12 @@ your pod would be located at `http://localhost:3000/test/`
 and your generated WebID would be `http://localhost:3000/test/profile/card#me`.
 
 The generated name also depends on the configuration you chose for your server.
-If you are using the subdomain feature, 
+If you are using the subdomain feature,
 such as being done in the `config/memory-subdomains.json` configuration,
 the generated pod URL would be `http://test.localhost:3000/`.
 
 ## Logging in
+
 When using an authenticating client,
 you will be redirected to a login screen asking for your email and password.
 After that you will be redirected to a page showing some basic information about the client.
@@ -67,12 +72,14 @@ As a result the server will send a token back to the client
 that contains all the information needed to use your WebID.
 
 ## Forgot password
+
 If you forgot your password, you can recover it by going to `http://localhost:3000/idp/forgotpassword/`.
 There you can enter your email address to get a recovery mail to reset your password.
 This feature only works if a mail server was configured,
 which by default is not the case.
 
 ## JSON API
+
 All of the above happens through HTML pages provided by the server.
 By default, the server uses the templates found in `/templates/identity/email-password/`
 but different templates can be used through configuration.
@@ -80,6 +87,7 @@ but different templates can be used through configuration.
 These templates all make use of a JSON API exposed by the server.
 For example, when doing a GET request to `http://localhost:3000/idp/register/`
 with a JSON accept header, the following JSON is returned:
+
 ```json
 {
   "required": {
@@ -106,9 +114,11 @@ with a JSON accept header, the following JSON is returned:
   "apiVersion": "0.3"
 }
 ```
+
 The `required` and `optional` fields indicate which input fields are expected by the API.
 These correspond to the fields of the HTML registration page.
 To register a user, you can do a POST request with a JSON body containing the correct fields:
+
 ```json
 {
   "email": "test@example.com",
@@ -121,6 +131,7 @@ To register a user, you can do a POST request with a JSON body containing the co
   "podName": "test"
 }
 ```
+
 Two fields here that are not covered on the HTML page above are `rootPod` and `template`.
 `rootPod` tells the server to put the pod in the root of the server instead of a location based on the `podName`.
 By default the server will reject requests where this is `true`, except during setup.
@@ -129,15 +140,17 @@ which is a very custom setup where every pod can have a different Components.js
 so this value can usually be ignored.
 
 ## IDP configuration
+
 The above descriptions cover server behaviour with most default configurations,
 but just like any other feature, there are several features that can be changed
 through the imports in your configuration file.
 
-All available options can be found in 
+All available options can be found in
 the [`config/identity/` folder](https://github.com/CommunitySolidServer/CommunitySolidServer/tree/main/config/identity).
 Below we go a bit deeper into the available options
 
 ### access
+
 The `access` option allows you to set authorization restrictions on the IDP API when enabled,
 similar to how authorization works on the LDP requests on the server.
 For example, if the server uses WebACL as authorization scheme,
@@ -151,16 +164,19 @@ All of the above is only relevant if you use the `restricted.json` setting for t
 When you use `public.json` the API will simply always be accessible by everyone.
 
 ### email
+
 In case you want users to be able to reset their password when they forget it,
 you will need to tell the server which email server to use to send reset mails.
 `example.json` contains an example of what this looks like,
 which you will need to copy over to your base configuration and then remove the `config/identity/email` import.
 
 ### handler
+
 There is only one option here. This import contains all the core components necessary to make the IDP work.
 In case you need to make some changes to core IDP settings, this is where you would have to look.
 
 ### pod
+
 The `pod` options determines how pods are created. `static.json` is the expected pod behaviour as described above.
 `dynamic.json` is an experimental feature that allows users
 to have a custom Components.js configuration for their own pod.
@@ -168,6 +184,7 @@ When using such a setup, a JSON file will be written containing all the informat
 so they can be recreated when the server restarts.
 
 ### registration
+
 This setting allows you to enable/disable registration on the server.
 Disabling registration here does not disable registration during setup,
 meaning you can still use this server as an IDP with the account created there.

documentation/markdown/usage/metadata.md

@@ -20,7 +20,7 @@ has `http://example.org/resource.meta` as its description resource.
 ## How to edit the metadata of a resource
 
 Editing the metadata of a resource is performed by editing the description resource directly.
-This can only be done using `PATCH` requests 
+This can only be done using `PATCH` requests
 (see [example workflow](#example-of-a-workflow-for-editing-a-description-resource)).
 
 `PUT` requests on description resources are not allowed,
@@ -38,17 +38,18 @@ The CSS will throw an error (409 `ConflictHttpError`) when trying to change this
 
 ### Preserving metadata
 
-`PUT` requests on a resource will reset the description resource. 
+`PUT` requests on a resource will reset the description resource.
 There is however a way to keep the contents of description resource prior to the `PUT` request:
 adding the HTTP `Link` header targeting the description resource with `rel="preserve"`.
 
-When the resource URL is `http://localhost:3000/foobar`, preserving its description resource when updating its contents can be achieved like in the following example:
+When the resource URL is `http://localhost:3000/foobar`, preserving its description resource when updating its contents
+can be achieved like in the following example:
 
 ```shell
 curl -X PUT 'http://localhost:3000/foobar' \
 -H 'Content-Type: text/turtle' \
 -H 'Link: <http://localhost:3000/foobar.meta>;rel="preserve"' \
--d "<ex:s> <ex:p> <ex:o>." 
+-d "<ex:s> <ex:p> <ex:o>."
 ```
 
 ## Impact on creating containers
@@ -80,6 +81,7 @@ which will produce a response with at least these headers:
 HTTP/1.1 200 OK
 Link: <http://localhost:3000/foo/.meta>; rel="describedby"
 ```
+
 Now that we have the URL of the description resource,
 we create a patch for adding the inbox in the description of the resource.
 
@@ -96,7 +98,9 @@ After this update, we can verify that the inbox is added by performing a GET req
 ```shell
 curl 'http://localhost:3000/foo/.meta'
 ```
+
 With as result for the body
+
 ```turtle
 @prefix dc: <http://purl.org/dc/terms/>.
 @prefix ldp: <http://www.w3.org/ns/ldp#>.

documentation/markdown/usage/seeding-pods.md

@@ -1,12 +1,13 @@
 # How to seed Accounts and Pods
 
-If you need to seed accounts and pods, 
+If you need to seed accounts and pods,
 the `--seededPodConfigJson` command line option can be used
 with as value the path to a JSON file containing configurations for every required pod.
-The file needs to contain an array of JSON objects, 
+The file needs to contain an array of JSON objects,
-with each object containing at least a `podName`, `email`, and `password` field. 
+with each object containing at least a `podName`, `email`, and `password` field.
 
 For example:
+
 ```json
 [
   {
@@ -17,10 +18,11 @@ For example:
 ]
 ```
 
-You may optionally specify other parameters 
+You may optionally specify other parameters
 as described in the [Identity Provider documentation](identity-provider.md#json-api).
 
 For example, to set up a pod without registering the generated WebID with the Identity Provider:
+
 ```json
 [
   {

package-lock.json

@@ -101,6 +101,7 @@
         "husky": "^4.3.8",
         "jest": "^27.5.1",
         "jest-rdf": "^1.7.0",
+        "markdownlint-cli2": "^0.5.1",
         "node-mocks-http": "^1.11.0",
         "nodemon": "^2.0.19",
         "set-cookie-parser": "^2.5.1",
@@ -11310,6 +11311,15 @@
       "integrity": "sha1-HADHQ7QzzQpOgHWPe2SldEDZ/wA=",
       "dev": true
     },
+    "node_modules/linkify-it": {
+      "version": "4.0.1",
+      "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-4.0.1.tgz",
+      "integrity": "sha512-C7bfi1UZmoj8+PQx22XyeXCuBlokoyWQL5pWSP+EI6nzRylyThouddufc2c1NDIcP9k5agmN9fLpA7VNJfIiqw==",
+      "dev": true,
+      "dependencies": {
+        "uc.micro": "^1.0.1"
+      }
+    },
     "node_modules/load-json-file": {
       "version": "4.0.0",
       "resolved": "https://registry.npmjs.org/load-json-file/-/load-json-file-4.0.0.tgz",
@@ -11507,6 +11517,123 @@
         "node": ">=8"
       }
     },
+    "node_modules/markdown-it": {
+      "version": "13.0.1",
+      "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-13.0.1.tgz",
+      "integrity": "sha512-lTlxriVoy2criHP0JKRhO2VDG9c2ypWCsT237eDiLqi09rmbKoUetyGHq2uOIRoRS//kfoJckS0eUzzkDR+k2Q==",
+      "dev": true,
+      "dependencies": {
+        "argparse": "^2.0.1",
+        "entities": "~3.0.1",
+        "linkify-it": "^4.0.1",
+        "mdurl": "^1.0.1",
+        "uc.micro": "^1.0.5"
+      },
+      "bin": {
+        "markdown-it": "bin/markdown-it.js"
+      }
+    },
+    "node_modules/markdown-it/node_modules/argparse": {
+      "version": "2.0.1",
+      "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
+      "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==",
+      "dev": true
+    },
+    "node_modules/markdownlint": {
+      "version": "0.26.2",
+      "resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.26.2.tgz",
+      "integrity": "sha512-2Am42YX2Ex5SQhRq35HxYWDfz1NLEOZWWN25nqd2h3AHRKsGRE+Qg1gt1++exW792eXTrR4jCNHfShfWk9Nz8w==",
+      "dev": true,
+      "dependencies": {
+        "markdown-it": "13.0.1"
+      },
+      "engines": {
+        "node": ">=14"
+      }
+    },
+    "node_modules/markdownlint-cli2": {
+      "version": "0.5.1",
+      "resolved": "https://registry.npmjs.org/markdownlint-cli2/-/markdownlint-cli2-0.5.1.tgz",
+      "integrity": "sha512-f3Nb1GF/c8YSrV/FntsCWzpa5mLFJRlO+wzEgv+lkNQjU6MZflUwc2FbyEDPTo6oVhP2VyUOkK0GkFgfuktl1w==",
+      "dev": true,
+      "dependencies": {
+        "globby": "13.1.2",
+        "markdownlint": "0.26.2",
+        "markdownlint-cli2-formatter-default": "0.0.3",
+        "micromatch": "4.0.5",
+        "strip-json-comments": "5.0.0",
+        "yaml": "2.1.1"
+      },
+      "bin": {
+        "markdownlint-cli2": "markdownlint-cli2.js",
+        "markdownlint-cli2-config": "markdownlint-cli2-config.js",
+        "markdownlint-cli2-fix": "markdownlint-cli2-fix.js"
+      },
+      "engines": {
+        "node": ">=14"
+      }
+    },
+    "node_modules/markdownlint-cli2-formatter-default": {
+      "version": "0.0.3",
+      "resolved": "https://registry.npmjs.org/markdownlint-cli2-formatter-default/-/markdownlint-cli2-formatter-default-0.0.3.tgz",
+      "integrity": "sha512-QEAJitT5eqX1SNboOD+SO/LNBpu4P4je8JlR02ug2cLQAqmIhh8IJnSK7AcaHBHhNADqdGydnPpQOpsNcEEqCw==",
+      "dev": true,
+      "peerDependencies": {
+        "markdownlint-cli2": ">=0.0.4"
+      }
+    },
+    "node_modules/markdownlint-cli2/node_modules/globby": {
+      "version": "13.1.2",
+      "resolved": "https://registry.npmjs.org/globby/-/globby-13.1.2.tgz",
+      "integrity": "sha512-LKSDZXToac40u8Q1PQtZihbNdTYSNMuWe+K5l+oa6KgDzSvVrHXlJy40hUP522RjAIoNLJYBJi7ow+rbFpIhHQ==",
+      "dev": true,
+      "dependencies": {
+        "dir-glob": "^3.0.1",
+        "fast-glob": "^3.2.11",
+        "ignore": "^5.2.0",
+        "merge2": "^1.4.1",
+        "slash": "^4.0.0"
+      },
+      "engines": {
+        "node": "^12.20.0 || ^14.13.1 || >=16.0.0"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/markdownlint-cli2/node_modules/slash": {
+      "version": "4.0.0",
+      "resolved": "https://registry.npmjs.org/slash/-/slash-4.0.0.tgz",
+      "integrity": "sha512-3dOsAHXXUkQTpOYcoAxLIorMTp4gIQr5IW3iVb7A7lFIp0VHhnynm9izx6TssdrIcVIESAlVjtnO2K8bg+Coew==",
+      "dev": true,
+      "engines": {
+        "node": ">=12"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/markdownlint-cli2/node_modules/strip-json-comments": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/strip-json-comments/-/strip-json-comments-5.0.0.tgz",
+      "integrity": "sha512-V1LGY4UUo0jgwC+ELQ2BNWfPa17TIuwBLg+j1AA/9RPzKINl1lhxVEu2r+ZTTO8aetIsUzE5Qj6LMSBkoGYKKw==",
+      "dev": true,
+      "engines": {
+        "node": ">=14.16"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
+    "node_modules/markdownlint-cli2/node_modules/yaml": {
+      "version": "2.1.1",
+      "resolved": "https://registry.npmjs.org/yaml/-/yaml-2.1.1.tgz",
+      "integrity": "sha512-o96x3OPo8GjWeSLF+wOAbrPfhFOGY0W00GNaxCDv+9hkcDJEnev1yh8S7pgHF0ik6zc8sQLuL8hjHjJULZp8bw==",
+      "dev": true,
+      "engines": {
+        "node": ">= 14"
+      }
+    },
     "node_modules/marked": {
       "version": "4.0.18",
       "resolved": "https://registry.npmjs.org/marked/-/marked-4.0.18.tgz",
@@ -11518,6 +11645,12 @@
         "node": ">= 12"
       }
     },
+    "node_modules/mdurl": {
+      "version": "1.0.1",
+      "resolved": "https://registry.npmjs.org/mdurl/-/mdurl-1.0.1.tgz",
+      "integrity": "sha512-/sKlQJCBYVY9Ers9hqzKou4H6V5UWc/M59TH2dvkt+84itfnq7uFOMLpOiOS4ujvHP4etln18fmIxA5R5fll0g==",
+      "dev": true
+    },
     "node_modules/media-typer": {
       "version": "0.3.0",
       "resolved": "https://registry.npmjs.org/media-typer/-/media-typer-0.3.0.tgz",
@@ -11658,13 +11791,13 @@
       }
     },
     "node_modules/micromatch": {
-      "version": "4.0.4",
+      "version": "4.0.5",
-      "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.4.tgz",
+      "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.5.tgz",
-      "integrity": "sha512-pRmzw/XUcwXGpD9aI9q/0XOwLNygjETJ8y0ao0wdqprrzDa4YnxLcz7fQRZr8voh8V10kGhABbNcHVk5wHgWwg==",
+      "integrity": "sha512-DMy+ERcEW2q8Z2Po+WNXuw3c5YaUSFjAO5GsJqfEl7UjvtIuFKO6ZrKvcItdy98dwFI2N1tg3zNIdKaQT+aNdA==",
       "dev": true,
       "dependencies": {
-        "braces": "^3.0.1",
+        "braces": "^3.0.2",
-        "picomatch": "^2.2.3"
+        "picomatch": "^2.3.1"
       },
       "engines": {
         "node": ">=8.6"
@@ -12561,9 +12694,9 @@
       "dev": true
     },
     "node_modules/picomatch": {
-      "version": "2.3.0",
+      "version": "2.3.1",
-      "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.0.tgz",
+      "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz",
-      "integrity": "sha512-lY1Q/PiJGC2zOv/z391WOTD+Z02bCgsFfvxoXXf6h7kv9o+WmsmzYqrAwY63sNgOxE4xEdq0WyUnXfKeBrSvYw==",
+      "integrity": "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==",
       "dev": true,
       "engines": {
         "node": ">=8.6"
@@ -14562,6 +14695,12 @@
         "node": ">=4.2.0"
       }
     },
+    "node_modules/uc.micro": {
+      "version": "1.0.6",
+      "resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-1.0.6.tgz",
+      "integrity": "sha512-8Y75pvTYkLJW2hWQHXxoqRgV7qb9B+9vFEtidML+7koHUFapnVJAZ6cKs+Qjz5Aw3aZWHMC6u0wJE3At+nSGwA==",
+      "dev": true
+    },
     "node_modules/uglify-js": {
       "version": "3.12.0",
       "resolved": "https://registry.npmjs.org/uglify-js/-/uglify-js-3.12.0.tgz",
@@ -24120,6 +24259,15 @@
       "integrity": "sha1-HADHQ7QzzQpOgHWPe2SldEDZ/wA=",
       "dev": true
     },
+    "linkify-it": {
+      "version": "4.0.1",
+      "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-4.0.1.tgz",
+      "integrity": "sha512-C7bfi1UZmoj8+PQx22XyeXCuBlokoyWQL5pWSP+EI6nzRylyThouddufc2c1NDIcP9k5agmN9fLpA7VNJfIiqw==",
+      "dev": true,
+      "requires": {
+        "uc.micro": "^1.0.1"
+      }
+    },
     "load-json-file": {
       "version": "4.0.0",
       "resolved": "https://registry.npmjs.org/load-json-file/-/load-json-file-4.0.0.tgz",
@@ -24290,11 +24438,101 @@
       "integrity": "sha512-glc9y00wgtwcDmp7GaE/0b0OnxpNJsVf3ael/An6Fe2Q51LLwN1er6sdomLRzz5h0+yMpiYLhWYF5R7HeqVd4g==",
       "dev": true
     },
+    "markdown-it": {
+      "version": "13.0.1",
+      "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-13.0.1.tgz",
+      "integrity": "sha512-lTlxriVoy2criHP0JKRhO2VDG9c2ypWCsT237eDiLqi09rmbKoUetyGHq2uOIRoRS//kfoJckS0eUzzkDR+k2Q==",
+      "dev": true,
+      "requires": {
+        "argparse": "^2.0.1",
+        "entities": "~3.0.1",
+        "linkify-it": "^4.0.1",
+        "mdurl": "^1.0.1",
+        "uc.micro": "^1.0.5"
+      },
+      "dependencies": {
+        "argparse": {
+          "version": "2.0.1",
+          "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
+          "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==",
+          "dev": true
+        }
+      }
+    },
+    "markdownlint": {
+      "version": "0.26.2",
+      "resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.26.2.tgz",
+      "integrity": "sha512-2Am42YX2Ex5SQhRq35HxYWDfz1NLEOZWWN25nqd2h3AHRKsGRE+Qg1gt1++exW792eXTrR4jCNHfShfWk9Nz8w==",
+      "dev": true,
+      "requires": {
+        "markdown-it": "13.0.1"
+      }
+    },
+    "markdownlint-cli2": {
+      "version": "0.5.1",
+      "resolved": "https://registry.npmjs.org/markdownlint-cli2/-/markdownlint-cli2-0.5.1.tgz",
+      "integrity": "sha512-f3Nb1GF/c8YSrV/FntsCWzpa5mLFJRlO+wzEgv+lkNQjU6MZflUwc2FbyEDPTo6oVhP2VyUOkK0GkFgfuktl1w==",
+      "dev": true,
+      "requires": {
+        "globby": "13.1.2",
+        "markdownlint": "0.26.2",
+        "markdownlint-cli2-formatter-default": "0.0.3",
+        "micromatch": "4.0.5",
+        "strip-json-comments": "5.0.0",
+        "yaml": "2.1.1"
+      },
+      "dependencies": {
+        "globby": {
+          "version": "13.1.2",
+          "resolved": "https://registry.npmjs.org/globby/-/globby-13.1.2.tgz",
+          "integrity": "sha512-LKSDZXToac40u8Q1PQtZihbNdTYSNMuWe+K5l+oa6KgDzSvVrHXlJy40hUP522RjAIoNLJYBJi7ow+rbFpIhHQ==",
+          "dev": true,
+          "requires": {
+            "dir-glob": "^3.0.1",
+            "fast-glob": "^3.2.11",
+            "ignore": "^5.2.0",
+            "merge2": "^1.4.1",
+            "slash": "^4.0.0"
+          }
+        },
+        "slash": {
+          "version": "4.0.0",
+          "resolved": "https://registry.npmjs.org/slash/-/slash-4.0.0.tgz",
+          "integrity": "sha512-3dOsAHXXUkQTpOYcoAxLIorMTp4gIQr5IW3iVb7A7lFIp0VHhnynm9izx6TssdrIcVIESAlVjtnO2K8bg+Coew==",
+          "dev": true
+        },
+        "strip-json-comments": {
+          "version": "5.0.0",
+          "resolved": "https://registry.npmjs.org/strip-json-comments/-/strip-json-comments-5.0.0.tgz",
+          "integrity": "sha512-V1LGY4UUo0jgwC+ELQ2BNWfPa17TIuwBLg+j1AA/9RPzKINl1lhxVEu2r+ZTTO8aetIsUzE5Qj6LMSBkoGYKKw==",
+          "dev": true
+        },
+        "yaml": {
+          "version": "2.1.1",
+          "resolved": "https://registry.npmjs.org/yaml/-/yaml-2.1.1.tgz",
+          "integrity": "sha512-o96x3OPo8GjWeSLF+wOAbrPfhFOGY0W00GNaxCDv+9hkcDJEnev1yh8S7pgHF0ik6zc8sQLuL8hjHjJULZp8bw==",
+          "dev": true
+        }
+      }
+    },
+    "markdownlint-cli2-formatter-default": {
+      "version": "0.0.3",
+      "resolved": "https://registry.npmjs.org/markdownlint-cli2-formatter-default/-/markdownlint-cli2-formatter-default-0.0.3.tgz",
+      "integrity": "sha512-QEAJitT5eqX1SNboOD+SO/LNBpu4P4je8JlR02ug2cLQAqmIhh8IJnSK7AcaHBHhNADqdGydnPpQOpsNcEEqCw==",
+      "dev": true,
+      "requires": {}
+    },
     "marked": {
       "version": "4.0.18",
       "resolved": "https://registry.npmjs.org/marked/-/marked-4.0.18.tgz",
       "integrity": "sha512-wbLDJ7Zh0sqA0Vdg6aqlbT+yPxqLblpAZh1mK2+AO2twQkPywvvqQNfEPVwSSRjZ7dZcdeVBIAgiO7MMp3Dszw=="
     },
+    "mdurl": {
+      "version": "1.0.1",
+      "resolved": "https://registry.npmjs.org/mdurl/-/mdurl-1.0.1.tgz",
+      "integrity": "sha512-/sKlQJCBYVY9Ers9hqzKou4H6V5UWc/M59TH2dvkt+84itfnq7uFOMLpOiOS4ujvHP4etln18fmIxA5R5fll0g==",
+      "dev": true
+    },
     "media-typer": {
       "version": "0.3.0",
       "resolved": "https://registry.npmjs.org/media-typer/-/media-typer-0.3.0.tgz",
@@ -24402,13 +24640,13 @@
       }
     },
     "micromatch": {
-      "version": "4.0.4",
+      "version": "4.0.5",
-      "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.4.tgz",
+      "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.5.tgz",
-      "integrity": "sha512-pRmzw/XUcwXGpD9aI9q/0XOwLNygjETJ8y0ao0wdqprrzDa4YnxLcz7fQRZr8voh8V10kGhABbNcHVk5wHgWwg==",
+      "integrity": "sha512-DMy+ERcEW2q8Z2Po+WNXuw3c5YaUSFjAO5GsJqfEl7UjvtIuFKO6ZrKvcItdy98dwFI2N1tg3zNIdKaQT+aNdA==",
       "dev": true,
       "requires": {
-        "braces": "^3.0.1",
+        "braces": "^3.0.2",
-        "picomatch": "^2.2.3"
+        "picomatch": "^2.3.1"
       }
     },
     "mime": {
@@ -25054,9 +25292,9 @@
       "dev": true
     },
     "picomatch": {
-      "version": "2.3.0",
+      "version": "2.3.1",
-      "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.0.tgz",
+      "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz",
-      "integrity": "sha512-lY1Q/PiJGC2zOv/z391WOTD+Z02bCgsFfvxoXXf6h7kv9o+WmsmzYqrAwY63sNgOxE4xEdq0WyUnXfKeBrSvYw==",
+      "integrity": "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==",
       "dev": true
     },
     "pify": {
@@ -26615,6 +26853,12 @@
       "integrity": "sha512-C0WQT0gezHuw6AdY1M2jxUO83Rjf0HP7Sk1DtXj6j1EwkQNZrHAg2XPWlq62oqEhYvONq5pkC2Y9oPljWToLmQ==",
       "dev": true
     },
+    "uc.micro": {
+      "version": "1.0.6",
+      "resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-1.0.6.tgz",
+      "integrity": "sha512-8Y75pvTYkLJW2hWQHXxoqRgV7qb9B+9vFEtidML+7koHUFapnVJAZ6cKs+Qjz5Aw3aZWHMC6u0wJE3At+nSGwA==",
+      "dev": true
+    },
     "uglify-js": {
       "version": "3.12.0",
       "resolved": "https://registry.npmjs.org/uglify-js/-/uglify-js-3.12.0.tgz",

package.json

@@ -55,7 +55,10 @@
     "docker:stop": "./test/docker/docker-stop.sh",
     "typedocs": "typedoc --customCss ./documentation/typedoc.css",
     "jest": "jest --coverageReporters text-summary --",
-    "lint": "eslint . --cache --ignore-path .gitignore --max-warnings 0",
+    "lint": "npm run lint:ts && npm run lint:markdown",
+    "lint:ts": "eslint . --cache --ignore-path .gitignore --max-warnings 0",
+    "lint:markdown": "markdownlint-cli2",
+    "lint:markdown:fix": "markdownlint-cli2-fix",
     "prepare": "npm run build",
     "release": "commit-and-tag-version",
     "postrelease": "ts-node ./scripts/finalizeRelease.ts",
@@ -171,6 +174,7 @@
     "@typescript-eslint/eslint-plugin": "^5.3.0",
     "@typescript-eslint/parser": "^5.3.0",
     "cheerio": "^1.0.0-rc.12",
+    "commit-and-tag-version": "^10.1.0",
     "componentsjs-generator": "^3.0.3",
     "eslint": "^8.21.0",
     "eslint-config-es": "4.1.0",
@@ -184,6 +188,7 @@
     "husky": "^4.3.8",
     "jest": "^27.5.1",
     "jest-rdf": "^1.7.0",
+    "markdownlint-cli2": "^0.5.1",
     "node-mocks-http": "^1.11.0",
     "nodemon": "^2.0.19",
     "set-cookie-parser": "^2.5.1",