Merge branch 'main' into versions/next-major

CHANGELOG.md

@@ -3,6 +3,35 @@
 
 All notable changes to this project will be documented in this file.
 
+## [7.0.3](https://github.com/CommunitySolidServer/CommunitySolidServer/compare/v7.0.2...v7.0.3) (2024-01-05)
+
+### Features
+
+* Support default mainModulePath when creating App ([c6ec45c](https://github.com/CommunitySolidServer/CommunitySolidServer/commit/c6ec45c7c0fb91a1c1365e9a0139e4fdaf8838d6))
+
+### Fixes
+
+* Encode WebID ownership tokens ([277a0d0](https://github.com/CommunitySolidServer/CommunitySolidServer/commit/277a0d0ab724074ed96940836ecc973a8533c538))
+* Fix pod base URL in README template ([4e7929f](https://github.com/CommunitySolidServer/CommunitySolidServer/commit/4e7929f6d2b72fbb0a03e8f6e64955239f41c837))
+* Only require append when creating with PUT ([a0b7ee4](https://github.com/CommunitySolidServer/CommunitySolidServer/commit/a0b7ee42f3a39cdd8fe2dbf1470e53f57ea62aba))
+
+### Chores
+
+* Remove Docker arm builds ([648ce1f](https://github.com/CommunitySolidServer/CommunitySolidServer/commit/648ce1fba8737dc7a008ff987de161e5902f9d09))
+* Update linting dependency ([3a9b0d6](https://github.com/CommunitySolidServer/CommunitySolidServer/commit/3a9b0d69f01d6f0490983eda4ff8000798e10dcc))
+
+### Documentation
+
+* Explain how to use AppRunner to start a server instance ([716c3c3](https://github.com/CommunitySolidServer/CommunitySolidServer/commit/716c3c308933a10382d6726a70b5b77a62cfb787))
+* Explain that users need to log in for client credentials ([dca71bc](https://github.com/CommunitySolidServer/CommunitySolidServer/commit/dca71bc5b82a9790d861babdcb1dd231c99dd042))
+* Fix links ([1f88864](https://github.com/CommunitySolidServer/CommunitySolidServer/commit/1f888645d6619e253082f4bf0ed20e7ae4e4c38b))
+* Describe server feature set ([c64a1a2](https://github.com/CommunitySolidServer/CommunitySolidServer/commit/c64a1a241ddd975f22eb223d545c938dfc8cb63c))
+* Fix Typo `is -> if` ([355f7dd](https://github.com/CommunitySolidServer/CommunitySolidServer/commit/355f7dd1c7b9be14c3e243acb5c4634f3a800442))
+
+### Testing
+
+* Run tests on Node 21 ([8f74fc8](https://github.com/CommunitySolidServer/CommunitySolidServer/commit/8f74fc82ad8a611bf96c293748bc5c01c859cdeb))
+
 ## [7.0.2](https://github.com/CommunitySolidServer/CommunitySolidServer/compare/v7.0.1...v7.0.2) (2023-11-20)
 
 ### Features

documentation/markdown/contributing/release.md

@@ -1,34 +1,37 @@
-# Releasing a new major version
+# Releasing a new version
 
 This is only relevant if you are a developer with push access responsible for doing a new release.
 
 Steps to follow:
 
-* Merge `main` into `versions/next-major`.
+* **Major** releases only:
+    * Merge `main` into `versions/next-major`.
 * Verify if there are issues when upgrading an existing installation to the new version.
     * Can the data still be accessed?
     * Does authentication still work?
     * Is there an issue upgrading any of the dependent repositories (see below for links)?
     * 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.
+* **Major** and **Minor** releases:
+    * Verify that the `RELEASE_NOTES.md` are correct.
+* `npm run release -- -r major/minor/patch`
+    * Automatically updates Components.js references to the new version in case of a major release.
       Committed with `chore(release): Update configs to vx.0.0`.
     * Updates the `package.json`, and generates the new entries in `CHANGELOG.md`.
-      Commits 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
+      Commits with `chore(release): Release version vx.y.z of the npm package`
+    * Optionally run `npx commit-and-tag-version -r major/minor/patch --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.
     * 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/next-major` into `main` and push.
+* **Major** releases only:
+    * Merge `versions/next-major` into `main` and push.
 * Do a GitHub release.
 * `npm publish`
-    * `npm dist-tag add @solid/community-server@x.0.0 next`
-* Rename the `versions/x.0.0` branch to the next version.
+* If there is no **pre-release** of a higher version:
+    * `npm dist-tag add @solid/community-server@x.y.z next`
 * Potentially upgrade dependent repositories:
     * Recipes at <https://github.com/CommunitySolidServer/recipes/>
     * Tutorials at <https://github.com/CommunitySolidServer/tutorials/>
@@ -40,9 +43,3 @@ Steps to follow:
 * Version with `npm run release -- -r major --prerelease alpha`
 * Do not merge `versions/next-major` into `main`.
 * Publish with `npm publish --tag next`.
-* Do not update the branch or anything related.
-
-## Changes when doing a minor release
-
-* Version with `npm run release -- -r minor`
-* Do not merge `versions/next-major` into `main`.

documentation/markdown/usage/client-credentials.md

@@ -100,11 +100,10 @@ Once you have an Access token, you can use it for authenticated requests until i
 
 ```ts
 import { buildAuthenticatedFetch } from '@inrupt/solid-client-authn-core';
-import fetch from 'node-fetch';
 
 // The DPoP key needs to be the same key as the one used in the previous step.
 // The Access token is the one generated in the previous step.
-const authFetch = await buildAuthenticatedFetch(fetch, accessToken, { dpopKey });
+const authFetch = await buildAuthenticatedFetch(accessToken, { dpopKey });
 // authFetch can now be used as a standard fetch function that will authenticate as your WebID.
 // This request will do a simple GET for example.
 const response = await authFetch('http://localhost:3000/private');

documentation/markdown/usage/dev-configuration.md

@@ -1,6 +1,62 @@
 # Configuring the CSS as a development server in another project
 
 It can be useful to use the CSS as local server to develop Solid applications against.
+There are several ways to configure and run a server in your project.
+Note that starting up the server takes some time so set your timeout high enough if you are using this in your tests.
+
+## Starting the server through code
+
+You can create a server instance in your code, or tests, by calling the `create` function of a new `AppRunner` instance.
+The resulting object has `start` and `stop` functions.
+The `create` function takes as input an object with 5 optional parameters
+which can all be used to define the server configuration.
+None of these are mandatory, if you don't think you need one you can probably ignore it.
+These are discussed below.
+
+### loaderProperties
+
+These values are specifically to configure how Components.js handles starting the server.
+Most of these are generally not going to be relevant,
+but here are some of those you might want to change:
+
+* **mainModulePath**: Determines where Components.js will look for components.
+                        Defaults to the folder where the server dependency is installed.
+                        In case you are making a custom component,
+                        this value needs to point to the directory of your project instead.
+* **logLevel**: The logging level of Components.js when building. Defaults to `warn`.
+
+### config
+
+The file path of the Components.js configuration that needs to be used.
+This can also be an array of configuration paths.
+The `@css:` prefix can be used for file paths to generate a path
+relative to the folder where the server dependency is installed.
+Defaults to `@css:config/default.json`.
+
+### variableBindings
+
+Allows you to assign values to the variables that are used in a Components.js configuration.
+For example, `{ 'urn:solid-server:default:variable:port': 3000  }` tells the server to use port 3000.
+
+### shorthand
+
+Allows you to assign values to parameters similarly as if you would call the server from the CLI.
+For example, `{ port: 3000  }` tells the server to use port 3000.
+
+This is very similar to the `variableBindings` field mentioned above,
+as CLI parameters all get translated into Components.js variables,
+although some get transformed before being put into a variable.
+If you are not sure which one to use, `shorthand` is the safer choice to use.
+
+### argv
+
+If used, this parameter expects a string array.
+Here you can provide the raw dump of CLI values,
+so you don't have to parse them yourself,
+should this be useful for your application.
+
+## Configuring the server in `package.json`
+
 As an alternative to using CLI arguments, or environment variables, the CSS can be configured in the `package.json` as follows:
 
 ```json
@@ -24,7 +80,7 @@ As an alternative to using CLI arguments, or environment variables, the CSS can
 ```
 
 These parameters will then be used when the `community-solid-server`
-command is executed as an npm script (as shown in the example above).
+command is executed as an `npm` script (as shown in the example above).
 Or whenever the `community-solid-server` command is executed in the same
 folder as the `package.json`.