Prettier Usage

.github/workflows/ci.yaml

@@ -0,0 +1,27 @@
+name: Default CI Pipeline
+
+on:
+    push:
+        branches: [master]
+    pull_request:
+        branches: [master]
+    workflow_dispatch:
+jobs:
+    setup:
+        name: Install dependencies and run build
+        runs-on: ubuntu-latest
+        steps:
+            - name: Checkout
+              uses: actions/checkout@v4
+            - name: Install
+              run: npm ci
+            - name: Build
+              run: npm run build
+    prettier:
+        name: Check coding style
+        runs-on: ubuntu-latest
+        steps:
+            - uses: actions/checkout@v4
+            - uses: Nerixyz/actionsx-prettier@v3-adj
+              with:
+                  args: --check .

.github/workflows/static.yml

@@ -2,42 +2,42 @@
 name: Deploy static content to Pages
 
 on:
-  # Runs on pushes targeting the default branch
-  push:
-    branches: ["gh-pages"]
+    # Runs on pushes targeting the default branch
+    push:
+        branches: ["gh-pages"]
 
-  # Allows you to run this workflow manually from the Actions tab
-  workflow_dispatch:
+    # Allows you to run this workflow manually from the Actions tab
+    workflow_dispatch:
 
 # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
 permissions:
-  contents: read
-  pages: write
-  id-token: write
+    contents: read
+    pages: write
+    id-token: write
 
 # Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
 # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
 concurrency:
-  group: "pages"
-  cancel-in-progress: false
+    group: "pages"
+    cancel-in-progress: false
 
 jobs:
-  # Single deploy job since we're just deploying
-  deploy:
-    environment:
-      name: github-pages
-      url: ${{ steps.deployment.outputs.page_url }}
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-      - name: Setup Pages
-        uses: actions/configure-pages@v5
-      - name: Upload artifact
-        uses: actions/upload-pages-artifact@v3
-        with:
-          # Upload entire repository
-          path: '.'
-      - name: Deploy to GitHub Pages
-        id: deployment
-        uses: actions/deploy-pages@v4
+    # Single deploy job since we're just deploying
+    deploy:
+        environment:
+            name: github-pages
+            url: ${{ steps.deployment.outputs.page_url }}
+        runs-on: ubuntu-latest
+        steps:
+            - name: Checkout
+              uses: actions/checkout@v4
+            - name: Setup Pages
+              uses: actions/configure-pages@v5
+            - name: Upload artifact
+              uses: actions/upload-pages-artifact@v3
+              with:
+                  # Upload entire repository
+                  path: "."
+            - name: Deploy to GitHub Pages
+              id: deployment
+              uses: actions/deploy-pages@v4

.prettierignore

@@ -0,0 +1,5 @@
+package-lock.json
+.docusaurus
+node_modules
+build
+.nyc_output

.prettierrc.json

@@ -0,0 +1,7 @@
+{
+    "trailingComma": "es5",
+    "printWidth": 120,
+    "singleQuote": false,
+    "tabWidth": 4,
+    "endOfLine": "lf"
+}

CODE_OF_CONDUCT.md

@@ -11,19 +11,19 @@ In the interest of fostering an open and welcoming environment, we as community
 
 Examples of behavior that contributes to creating a positive environment include:
 
--   Using welcoming and inclusive language
--   Being respectful of differing viewpoints and experiences
--   Gracefully accepting constructive criticism
--   Focusing on what is best for the community
--   Showing empathy towards other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
--   The use of sexualized language or imagery and unwelcome sexual attention or advances
--   Trolling, insulting/derogatory comments, and personal or political attacks
--   Public or private harassment
--   Publishing others' private information, such as a physical or electronic address, without explicit permission
--   Other conduct which could reasonably be considered inappropriate in a professional setting
+- The use of sexualized language or imagery and unwelcome sexual attention or advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
 
 ## Our Responsibilities
 

CONTRIBUTING.md

@@ -4,7 +4,7 @@ Thanks for your interest in this project. General information
 regarding source code management, builds, coding standards, and
 more can be found here:
 
-* https://projects.eclipse.org/projects/iot.thingweb/developer
+- https://projects.eclipse.org/projects/iot.thingweb/developer
 
 ## Legal Requirements
 
@@ -13,22 +13,22 @@ This process helps us in creating great open source software within a safe legal
 
 Thus, before your contribution can be accepted by the project team, contributors must electronically sign the [Eclipse Contributor Agreement (ECA)](http://www.eclipse.org/legal/ECA.php) and follow these preliminary steps:
 
-* Obtain an [Eclipse Foundation account](https://accounts.eclipse.org/)
-   * Anyone who currently uses Eclipse Bugzilla or Gerrit systems already has one of those
-   * Newcomers can [create a new account](https://accounts.eclipse.org/user/register?destination=user)
-* Add your GiHub username to your Eclipse Foundation account
-  * ([Log into Eclipse](https://accounts.eclipse.org/))
-  * Go to the *Edit Profile* tab
-  * Fill in the *GitHub ID* under *Social Media Links* and save
-* Sign the [Eclipse Contributor Agreement](http://www.eclipse.org/legal/ECA.php)
-  * ([Log into Eclipse](https://accounts.eclipse.org/))
-  * If the *Status* entry *Eclipse Contributor Agreement* has a green checkmark, the ECA is already signed
-  * If not, go to the *Eclipse Contributor Agreement* tab or follow the corresponding link under *Status*
-  * Fill out the form and sign it electronically
-* Sign-off every commit using the same email address used for your Eclipse account
-  * Set the Git user email address with `git config user.email "<your Eclipse account email>"`
-  * Add the `-s` flag when you make the commit(s), e.g. `git commit -s -m "feat: add support for magic"`
-* Open a [Pull Request](https://github.com/eclipse-thingweb/node-wot/pulls)
+- Obtain an [Eclipse Foundation account](https://accounts.eclipse.org/)
+    - Anyone who currently uses Eclipse Bugzilla or Gerrit systems already has one of those
+    - Newcomers can [create a new account](https://accounts.eclipse.org/user/register?destination=user)
+- Add your GiHub username to your Eclipse Foundation account
+    - ([Log into Eclipse](https://accounts.eclipse.org/))
+    - Go to the _Edit Profile_ tab
+    - Fill in the _GitHub ID_ under _Social Media Links_ and save
+- Sign the [Eclipse Contributor Agreement](http://www.eclipse.org/legal/ECA.php)
+    - ([Log into Eclipse](https://accounts.eclipse.org/))
+    - If the _Status_ entry _Eclipse Contributor Agreement_ has a green checkmark, the ECA is already signed
+    - If not, go to the _Eclipse Contributor Agreement_ tab or follow the corresponding link under _Status_
+    - Fill out the form and sign it electronically
+- Sign-off every commit using the same email address used for your Eclipse account
+    - Set the Git user email address with `git config user.email "<your Eclipse account email>"`
+    - Add the `-s` flag when you make the commit(s), e.g. `git commit -s -m "feat: add support for magic"`
+- Open a [Pull Request](https://github.com/eclipse-thingweb/node-wot/pulls)
 
 For more information, please see the Eclipse Committer Handbook:
 https://www.eclipse.org/projects/handbook/#resources-commit
@@ -37,6 +37,7 @@ https://www.eclipse.org/projects/handbook/#resources-commit
 
 Eclipse Thingweb uses Conventional Changelog, which structure Git commit messages in a way that allows automatic generation of changelogs.
 Commit messages must be structured as follows:
+
 ```
 <type>(<scope>): <subject>
 <BLANK LINE>
@@ -45,58 +46,63 @@ Commit messages must be structured as follows:
 <footer>
 ```
 
-* `<type>`: A noun specifying the type of change, followed by a colon and a space. The types allowed are:
-   * `feat`: A new feature
-   * `fix`: A bug fix
-   * `refactor`: Code change that neither fixes a bug or adds a feature (not relevant for end user)
-   * `perf`: Change improves performance
-   * `style`: Change does not affect the code (e.g., formatting, whitespaces)
-   * `test`: Adding missing tests
-   * `chore`: Change of build process or auxiliary tools
-   * `docs`: Documentation only changes
-* `<scope>`: Optional. A term of free choice specifying the place of the commit change, enclosed in parentheses. Examples:
-   * `feat(binding-coap): ...`
-   * `fix(cli): ...`
-   * `docs: ...` (no scope, as it is optional)
-* `<subject>`: A succinct description of the change, e.g., `add support for magic`
-   * Use the imperative, present tense: "add", not "added" nor "adds"
-   * Do not capitalize first letter: "add", not "Add"
-   * No dot (.) at the end
-* `<body>`: Optional. Can include the motivation for the change and contrast this with previous behavior.
-   * Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes"
-* `<footer>`: Optional. Can be used to automatically close GitHub Issues and to document breaking changes.
-   * The prefix `BREAKING CHANGE: ` idicates API breakage (corresponding to a major version change) and everything after is a description what changed and what needs to be done to migrate
-   * GitHub Issue controls such as `Fixes #123` or `Closes #4711` must come before a potential `BREAKING CHANGE: `.
+- `<type>`: A noun specifying the type of change, followed by a colon and a space. The types allowed are:
+    - `feat`: A new feature
+    - `fix`: A bug fix
+    - `refactor`: Code change that neither fixes a bug or adds a feature (not relevant for end user)
+    - `perf`: Change improves performance
+    - `style`: Change does not affect the code (e.g., formatting, whitespaces)
+    - `test`: Adding missing tests
+    - `chore`: Change of build process or auxiliary tools
+    - `docs`: Documentation only changes
+- `<scope>`: Optional. A term of free choice specifying the place of the commit change, enclosed in parentheses. Examples:
+    - `feat(binding-coap): ...`
+    - `fix(cli): ...`
+    - `docs: ...` (no scope, as it is optional)
+- `<subject>`: A succinct description of the change, e.g., `add support for magic`
+    - Use the imperative, present tense: "add", not "added" nor "adds"
+    - Do not capitalize first letter: "add", not "Add"
+    - No dot (.) at the end
+- `<body>`: Optional. Can include the motivation for the change and contrast this with previous behavior.
+    - Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes"
+- `<footer>`: Optional. Can be used to automatically close GitHub Issues and to document breaking changes.
+    - The prefix `BREAKING CHANGE: ` idicates API breakage (corresponding to a major version change) and everything after is a description what changed and what needs to be done to migrate
+    - GitHub Issue controls such as `Fixes #123` or `Closes #4711` must come before a potential `BREAKING CHANGE: `.
 
 Examples:
+
 ```
 docs: improve how to contribute
 ```
+
 ```
 feat(core): add support for magic
 
 Closes #110
 ```
+
 ```
 feat(core): add support for magic
 
 Simplify the API by reducing the number of functions.
 
 Closes #110
 BREAKING CHANGE: Change all calls to the API to the new `do()` function.
-``` 
+```
 
 ## Pull Requests and Feature Branches
 
-* Do not merge with master while developing a new feature or providing a fix in a new branch
-* Do a rebase if updates in the master such as a fix are required:
+- Do not merge with master while developing a new feature or providing a fix in a new branch
+- Do a rebase if updates in the master such as a fix are required:
+
 ```
 git checkout master && git pull && git checkout - && git rebase master
 ```
-* Pull Requests are merged using rebase
+
+- Pull Requests are merged using rebase
 
 ## Contact
 
 Contact the project developers via the project's "dev" list.
 
-* https://dev.eclipse.org/mailman/listinfo/thingweb-dev
+- https://dev.eclipse.org/mailman/listinfo/thingweb-dev

NOTICE.md

@@ -2,7 +2,7 @@
 
 This content is produced and maintained by the Eclipse Thingweb project.
 
--   Project home: https://projects.eclipse.org/projects/iot.thingweb
+- Project home: https://projects.eclipse.org/projects/iot.thingweb
 
 ## Trademarks
 

README.md

@@ -3,4 +3,5 @@
 This website is built using [Docusaurus](https://docusaurus.io/), a modern static website generator.
 
 ## Adopters
+
 If you are using any Eclipse Thingweb component within your organization, please support us by adding your logo to the [Eclipse IoT adopters list](https://iot.eclipse.org/adopters/#iot.thingweb). To do so, simply open an issue at [the Eclipse Gitlab](https://gitlab.eclipse.org/eclipsefdn/it/api/eclipsefdn-project-adopters/-/issues/new?issuable_template=adopter_request) by providing the name of your organization, its logo, and a link to your organization or team. You should be affiliated with that organization for the issue to be implemented.

SECURITY.md

@@ -2,7 +2,7 @@
 
 This content is produced and maintained by the Eclipse Thingweb project.
 
--   Project home: https://projects.eclipse.org/projects/iot.thingweb
+- Project home: https://projects.eclipse.org/projects/iot.thingweb
 
 ## Trademarks
 
@@ -41,6 +41,7 @@ another country, of encryption software. BEFORE using any encryption software,
 please check the country's laws, regulations and policies concerning the import,
 possession, or use, and re-export of encryption software, to see if this is
 permitted.
+
 <!--- https://www.eclipse.org/security/ --->
 
 _ISO 27005 defines vulnerability as:

babel.config.js

@@ -1,3 +1,3 @@
 module.exports = {
-  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
-};
+    presets: [require.resolve("@docusaurus/core/lib/babel/preset")],
+};

docs/introduction.md

@@ -1,10 +1,11 @@
 ---
 sidebar_position: 1
 ---
+
 # Introduction
 
 :::info
 
 For the moment the documentation page is still under construction. For more information about Thingweb and node-wot refer to this [`repository`](https://github.com/eclipse-thingweb/node-wot).
 
-:::
+:::