Prettier Usage (#141)

* add dependencies and config files

* run format

* fix prettier version

* devops: add basic ci workflow with prettier

* chore: run format

* chore: rerun npm install

* chore: run format

* chore: fix prettier to 3.3.3

* fix: correct file extension

* add gitattributes file

Author: egekorkan

.gitattributes

@@ -0,0 +1,39 @@
+# Set default behaviour, in case users don't have core.autocrlf set.
+* text=auto
+
+# Explicitly declare text files we want to always be normalized and converted
+# to native line endings on checkout.
+
+# Declare files that will always have LF line endings on checkout.
+*.c text eol=lf
+*.css text eol=lf
+*.cpp text eol=lf
+.editorconfig text eol=lf
+.gitattributes text eol=lf
+.gitignore text eol=lf
+.gitmodules text eol=lf
+*.gyp text eol=lf
+*.h text eol=lf
+*.hpp text eol=lf
+*.html text eol=lf
+*.js text eol=lf
+*.ts text eol=lf
+*.json text eol=lf
+LICENSE text eol=lf
+*.md text eol=lf
+*.puml text eol=lf
+*.svg text eol=lf
+*.sh text eol=lf
+*.sparql text eol=lf
+*.ttl text eol=lf
+*.yml text eol=lf
+
+# Declare files that will always have CRLF line endings on checkout.
+*.bat text eol=crlf
+*.cmd text eol=crlf
+
+# Denote all files that are truly binary and should not be modified.
+*.gif binary
+*.jpg binary
+*.node binary
+*.png binary

.github/workflows/ci.yml

@@ -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"
+}

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

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

@@ -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).
 
-:::
+:::