ci: added linter of the formatting with prettier

.github/workflows/lint-format.yml

@@ -0,0 +1,32 @@
+name: Prettier Check
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - main
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  format:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Set up Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: "latest"
+
+      - name: Install dependencies
+        run: npm install
+
+      - name: Run Prettier
+        run: npm run prettier:check

.gitignore

@@ -1,3 +1,4 @@
 /target
 /Cargo.lock
-.idea/
+.idea/
+node_modules/

README.md

@@ -91,9 +91,9 @@ impl ValueSelector<MyValue> for MyValueSelector {
 
 `LeaderElector` trait allows you to define specific conditions, how to select leader for consensus.
 
-__NOTE: it is important to provide deterministic mechanism,
+**NOTE: it is important to provide deterministic mechanism,
 because each participant will compute leader for itself,
-and in case it is not deterministic, state divergence occurs.__
+and in case it is not deterministic, state divergence occurs.**
 
 We also provide ready-to-use
 [DefaultLeaderElector](https://distributed-lab.github.io/bpcon/bpcon/leader/struct.DefaultLeaderElector.html)
@@ -141,17 +141,17 @@ We welcome you to check our [integration tests](./tests) for examples.
 In real world applications, we may categorize parties by their behavior to following:
 
 1. Good - party sends messages to other participants based on following events,
-    and correctly receives and processes messages from other parties.
+   and correctly receives and processes messages from other parties.
 
 2. Faulty - party has troubles receiving/sending messages.
-    These are simply mitigated by the weighed threshold and redundancy of consensus participants.
+   These are simply mitigated by the weighed threshold and redundancy of consensus participants.
 
 3. Malicious - party launches DDoS attack using unbounded sending of messages -
-    to deal with this, we introduce rate-limiting mechanism in accepting messages inside the `Party`,
-    however it is also ❗️ required by integrating 'external' system ❗️, which handles `P2P`, to attest to this, because otherwise receiving channel may get flooded by malicious messages and block messages from other parties.
-    Another way to cause trouble is by sending invalid messages. For this, each party has
-    a set of checks for certain fields like current ballot number, status, etc.
-    Additionally, if the state transition caused by incoming message errored, it does not impact the party in either way.
+   to deal with this, we introduce rate-limiting mechanism in accepting messages inside the `Party`,
+   however it is also ❗️ required by integrating 'external' system ❗️, which handles `P2P`, to attest to this, because otherwise receiving channel may get flooded by malicious messages and block messages from other parties.
+   Another way to cause trouble is by sending invalid messages. For this, each party has
+   a set of checks for certain fields like current ballot number, status, etc.
+   Additionally, if the state transition caused by incoming message errored, it does not impact the party in either way.
 
 ### Note on the leader 👑
 

package.json

@@ -0,0 +1,25 @@
+{
+  "name": "bpcon",
+  "description": "Generic Rust library for BPCon (Byzantine Paxos).",
+  "scripts": {
+    "prettier:fix": "prettier --cache --write .",
+    "prettier:check": "prettier --cache --check ."
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/distributed-lab/bpcon"
+  },
+  "keywords": [
+    "Rust",
+    "BPCon",
+    "DistributedLab"
+  ],
+  "author": "DistributedLab",
+  "bugs": {
+    "url": "https://github.com/distributed-lab/bpcon/issues"
+  },
+  "homepage": "https://github.com/distributed-lab/bpcon#readme",
+  "devDependencies": {
+    "prettier": "^3.3.3"
+  }
+}