iotaledger · Dr-Electron · Oct 10, 2023 · Apr 28, 2023 · May 2, 2023 · May 7, 2023
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
@@ -19,6 +19,10 @@ jobs:
         uses: ./.github/actions/prepare/
       - name: Lint Wiki
         run: yarn lint:check
+      # - name: Build Cli
+      #   run: yarn ./cli build
+      # - name: Lint IOTA Markdown
+      #   run: yarn lint:md:check
       - name: Format Wiki
         run: yarn format:check
   build:

diff --git a/.prettierignore b/.prettierignore
@@ -1,6 +1,10 @@
 # Dependencies
 /node_modules
 
+# Markdown files
+**/*.md
+**/*.mdx
+
 # External documentation
 /docs/external
 

diff --git a/cli/package.json b/cli/package.json
@@ -35,6 +35,7 @@
     "ink-text-input": "^4.0.3",
     "isomorphic-git": "^1.17.2",
     "link-check": "^5.2.0",
+    "markdownlint-cli2": "^0.8.1",
     "node-html-parser": "^6.1.10",
     "prettier": "2.8.8",
     "remark": "^14.0.2",

diff --git a/cli/src/commands/lint.tsx b/cli/src/commands/lint.tsx
@@ -0,0 +1,25 @@
+import { Command, Option } from 'clipanion';
+import { execute as shell } from '@yarnpkg/shell';
+
+const internalConfig = require.resolve(
+  '../markdownlint-cli2/default.markdownlint-cli2.cjs',
+);
+
+export class Lint extends Command {
+  static paths = [[`lint`]];
+  config = Option.String(`-c,--config`);
+  args = Option.Proxy();
+
+  async execute() {
+    return await shell(
+      'npx markdownlint-cli2 --config ' + internalConfig + ' ',
+      this.args,
+      {
+        env: {
+          CUSTOM_CONFIG: this.config,
+          ...process.env,
+        },
+      },
+    );
+  }
+}
diff --git a/cli/src/index.tsx b/cli/src/index.tsx
@@ -5,6 +5,7 @@ import { Builtins, Cli } from 'clipanion';
 import { Start } from './commands/start';
 import { Build } from './commands/build';
 import { Check } from './commands/check';
+import { Lint } from './commands/lint';
 import { Setup } from './commands/tutorial/configure';
 import { Default } from './commands/default';
 
@@ -21,6 +22,7 @@ cli.register(Builtins.VersionCommand);
 cli.register(Start);
 cli.register(Build);
 cli.register(Check);
+cli.register(Lint);
 cli.register(Setup);
 cli.register(Default);
 cli.runExit(args);
diff --git a/cli/src/markdownlint-cli2/default.markdownlint-cli2.cjs b/cli/src/markdownlint-cli2/default.markdownlint-cli2.cjs
@@ -0,0 +1,30 @@
+// @ts-check
+const _ = require('lodash');
+
+('use strict');
+
+const { env } = require('process');
+var custom_config = null;
+if (env.CUSTOM_CONFIG) {
+  custom_config = require(env.PWD + '/' + env.CUSTOM_CONFIG);
+}
+
+const default_config = {
+  config: {
+    MD007: {
+      indent: 2,
+    },
+    MD010: {
+      code_blocks: false,
+    },
+    MD013: false,
+    MD033: false,
+    MD034: false,
+    MD041: false,
+  },
+};
+
+const config = custom_config
+  ? _.defaultsDeep(custom_config, default_config)
+  : default_config;
+module.exports = config;
diff --git a/cli/test/markdownlint-cli2/custom.markdownlint-cli2.cjs b/cli/test/markdownlint-cli2/custom.markdownlint-cli2.cjs
@@ -0,0 +1,10 @@
+module.exports = {
+    "fix": true,
+    "config": {
+        "MD003": {
+            "style": "atx"
+        },
+    //    "MD032": true,
+    //    "MD047": false,
+    }
+};
diff --git a/cli/test/markdownlint-cli2/markdown.md b/cli/test/markdownlint-cli2/markdown.md
@@ -0,0 +1,20 @@
+# tHis-iS-A-wEiRd-hEaDeR
+
+Something something
+
+# ATX style H1
+
+## Closed ATX style H2 ##
+
+Setext style H1
+===============
+
+* Item 1
++ Item 2
+- Item 3
+
+```
+$ ls
+$ cat foo
+$ less bar
+```
diff --git a/cli/test/tutorial/docs/tutorial-basics/markdown-features.mdx b/cli/test/tutorial/docs/tutorial-basics/markdown-features.mdx
@@ -152,4 +152,4 @@ This is <Highlight color="#1877F2">Facebook blue</Highlight> !
 
 ## AddToMetaMaskButton
 
-<AddToMetaMaskButton />
+<AddToMetaMaskButton />
diff --git a/docs/build/identity.rs/0.6/docs/concepts/decentralized_identifiers/resolve.mdx b/docs/build/identity.rs/0.6/docs/concepts/decentralized_identifiers/resolve.mdx
@@ -112,7 +112,7 @@ advanced use cases where more control is desired. To accommodate for such situat
 - resolving all DID Documents of the distinct issuers of the credentials contained in the presentation
 - resolving the issuer's DID Document for a given verifiable credential
 
-## Resolving the history of a DID Document.
+## Resolving the history of a DID Document
 
 The fact that a DID Document [can be updated](./update.mdx) implies that the state of the DID Document can change over time, or in other words the result of resolving a DID
 also depends on when this operation was carried out. The `Resolver` provides a way to view the entire history of a DID Document (up to the time when the method is called).

diff --git a/docs/build/identity.rs/0.6/docs/decentralized_identity.mdx b/docs/build/identity.rs/0.6/docs/decentralized_identity.mdx
@@ -77,7 +77,7 @@ There is a growth in applications that generate Digital Twins for physical devic
 
 Security is a major barrier in advancing technologies that use IoT. Whether it is the smart devices in our own homes, or at a larger scale, the critical infrastructure of organizations and cities, security must be at the core. It is central to any globally-unifying identity solution. By integrating advanced research in cryptography and digital ledgers, and combining it with a scalable access and management system, security will become a core functionality of the systems we build. By using scalable device DIDs, integrating verification and reputation schemes, and allowing for transparent tamper-proof accountability, we begin to understand how we can future-proof the security of our systems, allowing us to start trusting the process, and not the patch.
 
-## One Framework. Any Identity.
+## One Framework. Any Identity
 
 :::note Framework
 

diff --git a/docs/build/identity.rs/0.6/docs/libraries/wasm/api_reference.mdx b/docs/build/identity.rs/0.6/docs/libraries/wasm/api_reference.mdx
@@ -4381,7 +4381,7 @@ The lack of an error returned from this method is in of itself not enough to con
 trusted. This section contains more information on additional checks that should be carried out before and after
 calling this method.
 
-#### The state of the supplied DID Documents.
+#### The state of the supplied DID Documents
 
 The caller must ensure that the DID Documents in `holder` and `issuers` are up-to-date. The convenience methods
 `Resolver::resolve_presentation_holder` and `Resolver::resolve_presentation_issuers`

diff --git a/docs/build/identity.rs/0.6/docs/libraries/wasm/getting_started.mdx b/docs/build/identity.rs/0.6/docs/libraries/wasm/getting_started.mdx
@@ -23,7 +23,7 @@ keywords:
 
 ## [Low-Level Examples](https://github.com/iotaledger/identity.rs/blob/support/v0.6/bindings/wasm/examples/README.md)
 
-## Install the library:
+## Install the library
 
 Latest Release: this version matches the main branch of this repository, is stable and will have changelogs.
 
@@ -116,7 +116,7 @@ The library loads the WASM file with an HTTP GET request, so the .wasm file must
 - Install `rollup-plugin-copy`:
 
 ```bash
-$ npm install rollup-plugin-copy --save-dev
+npm install rollup-plugin-copy --save-dev
 ```
 
 - Add the copy plugin usage to the `plugins` array under `rollup.config.js`:
@@ -142,7 +142,7 @@ copy({
 - Install `copy-webpack-plugin`:
 
 ```bash
-$ npm install copy-webpack-plugin --save-dev
+npm install copy-webpack-plugin --save-dev
 ```
 
 ```js

diff --git a/docs/build/identity.rs/0.6/docs/specs/didcomm/overview.mdx b/docs/build/identity.rs/0.6/docs/specs/didcomm/overview.mdx
@@ -28,7 +28,8 @@ The specification itself is technology agnostic. Much like the [DIDComm Messagin
 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
 "OPTIONAL" in this specification are to be interpreted as described in
-[BCP 14](https://www.rfc-editor.org/info/bcp14)[[RFC 2119]](https://www.rfc-editor.org/rfc/rfc2119.txt).
+<!-- markdownlint-disable-next-line MD011 MD052 -->
+[BCP 14](https://www.rfc-editor.org/info/bcp14)[(RFC 2119)]](https://www.rfc-editor.org/rfc/rfc2119.txt).
 
 ## Versioning
 

diff --git a/docs/build/identity.rs/0.6/docs/specs/didcomm/protocols/connection.mdx b/docs/build/identity.rs/0.6/docs/specs/didcomm/protocols/connection.mdx
@@ -196,7 +196,7 @@ Following a successful connection, the [invitee](#roles) sends its public keys n
 
 The `id` of the preceding [invitation](#invitation) message MUST be used as the `pthid` header property on this message. Both the `thid` and `pthid` properties MUST be omitted in the case of an implicit invitation when connecting to a public service endpoint of an [inviter](#roles). See [DIDComm Message Headers](https://identity.foundation/didcomm-messaging/spec/#message-headers) for more information.
 
-[^1] If present, the `recipientKey` sent by the [`invitee`](#roles) MUST match the key type (e.g. Ed25519, X25519) of one of the `recipientKeys` in the [invitation](#invitation) message, or of a `keyAgreement` public key attached to the [inviter`s](#roles) DID document in the case of an implicit invitation. The `recipientKey` should be omitted if no `recipientKeys` or `keyAgreement` sections are present, or if the [invitee](#roles) does not wish to use [anonymous encryption][anoncrypt] for the connection. An [inviter](#roles) may choose to reject connection messages that omit a `recipientKey`, terminating the connection.
+[^1] If present, the `recipientKey` sent by the [`invitee`](#roles) MUST match the key type (e.g. Ed25519, X25519) of one of the `recipientKeys` in the [invitation](#invitation) message, or of a `keyAgreement` public key attached to the [inviter's](#roles) DID document in the case of an implicit invitation. The `recipientKey` should be omitted if no `recipientKeys` or `keyAgreement` sections are present, or if the [invitee](#roles) does not wish to use [anonymous encryption][anoncrypt] for the connection. An [inviter](#roles) may choose to reject connection messages that omit a `recipientKey`, terminating the connection.
 
 [^2] Similar to the considerations for the [invitation](#invitation) message, implementors should avoid using a `DIDUrl` for the `recipientKey` or `routingKeys` as it may reveal the identity of the [invitee](#roles) to eavesdroppers prior to encryption being established. Using a `DIDUrl` for key rotation is less of a concern for a [connection](#connection) message as, unlike an [invitation](#invitation), the message is intended to be transient and should not persist beyond a single connection attempt.
 

diff --git a/docs/build/identity.rs/0.6/docs/workflow.mdx b/docs/build/identity.rs/0.6/docs/workflow.mdx
@@ -16,7 +16,7 @@ In this article you will learn about the software development process for the IO
 
 ## Issues
 
-Issues are opened when a certain task or problem is noted but cannot immediately be fixed. Issues may contain bug reports, requests, or larger topics. Please use the correct GitHub issue template for your issue type. Only IOTA Foundation members should use the task templates flagged for maintainers. You should make sure to [label](#issue-Labels) the issue correctly. As a contributor, you may also add issues to a certain [project](https://github.com/iotaledger/identity.rs/projects/).
+Issues are opened when a certain task or problem is noted but cannot immediately be fixed. Issues may contain bug reports, requests, or larger topics. Please use the correct GitHub issue template for your issue type. Only IOTA Foundation members should use the task templates flagged for maintainers. You should make sure to [label](#issue-labels) the issue correctly. As a contributor, you may also add issues to a certain [project](https://github.com/iotaledger/identity.rs/projects/).
 
 ## Git
 
@@ -59,7 +59,7 @@ We recommend integrating `dev` or `epic` regularly, depending on where the branc
 
 #### Epic (epic/)
 
-Long-lived `epic` branches should be created as soon as a feature is expected to require more than one PR. The `epic` branch should be branched from `dev` and should only accept merges that are related to the feature being developed. A PR should be opened as soon as the branch is created to publicly notify contributors about the development, the goals and requirements of the feature, and the existence of the branch. It is recommended you integrate `dev` often to reduce the possibility and potential size of merge conflicts. Epic branches must not be squash-merged, otherwise the [changelog generator](#Changelog) will not detect its constituent PRs.
+Long-lived `epic` branches should be created as soon as a feature is expected to require more than one PR. The `epic` branch should be branched from `dev` and should only accept merges that are related to the feature being developed. A PR should be opened as soon as the branch is created to publicly notify contributors about the development, the goals and requirements of the feature, and the existence of the branch. It is recommended you integrate `dev` often to reduce the possibility and potential size of merge conflicts. Epic branches must not be squash-merged, otherwise the [changelog generator](#changelog) will not detect its constituent PRs.
 
 ### Semantic Versioning
 
@@ -71,11 +71,11 @@ For more detailed information and an overview of advanced features, see [Semanti
 
 ### Changelog
 
-A changelog is a file describing a software project for humans to grasp the type and content of changes from version to version. Changelogs are closely related to the versioning of software, since individual changes are grouped into versions that are, in our case, referenced by a [SemVer string](#Semantic-Versioning). We generally follow the recommendations from [keepachangelog](https://keepachangelog.com/en/1.0.0/). The changelog in this project is generated from the titles and [labels](#PR-Labels) of [pull requests](#Pull-Requests).
+A changelog is a file describing a software project for humans to grasp the type and content of changes from version to version. Changelogs are closely related to the versioning of software, since individual changes are grouped into versions that are, in our case, referenced by a [SemVer string](#semantic-versioning). We generally follow the recommendations from [keepachangelog](https://keepachangelog.com/en/1.0.0/). The changelog in this project is generated from the titles and [labels](#pr-labels) of [pull requests](#pull-requests).
 
 #### PR labels
 
-Labels are used to categorize changes in [pull requests](#Pull-Requests). Adding a label will include the labeled [PR](#Pull-Requests) title in the related section of the generated [changelog](#Changelog).
+Labels are used to categorize changes in [pull requests](#pull-requests). Adding a label will include the labeled [PR](#pull-requests) title in the related section of the generated [changelog](#changelog).
 
 Changelogs are generated for the core Rust library and each binding separately. To attach a PR to a specific changelog, use the following labels:
 
@@ -91,17 +91,17 @@ It is also necessary to add an appropriate label for the type of change in the P
 
 ##### Changed
 
-Maps to the major version of [Semantic Versioning](#Semantic-Versioning).
+Maps to the major version of [Semantic Versioning](#semantic-versioning).
 labels: `Breaking change`
 
 ##### Added
 
-Maps to the minor version of [Semantic Versioning](#Semantic-Versioning).
+Maps to the minor version of [Semantic Versioning](#semantic-versioning).
 labels: `Added`
 
 ##### Patch
 
-Maps to the patch version of [Semantic Versioning](#Semantic-Versioning).
+Maps to the patch version of [Semantic Versioning](#semantic-versioning).
 labels: `Patch`
 
 ##### Deprecated
@@ -111,7 +111,7 @@ labels: `Deprecated`
 
 ##### Removed
 
-Marks features as being removed. Typically the features should have been deprecated in the previous version. This maps to the major version of [Semantic Versioning](#Semantic-Versioning).
+Marks features as being removed. Typically the features should have been deprecated in the previous version. This maps to the major version of [Semantic Versioning](#semantic-versioning).
 labels: `Removed`
 
 ##### Excluded tags
@@ -133,7 +133,7 @@ The following labels are used to categorize issues but do not have any effect on
 
 With the release process, we can deliver versions of our software to the community. We use sensible automation where it helps to remove tedium. However, some steps that require active decision-making remain manual.
 
-The final list of changes from the [changelog](#Changelog) informs the version of the release. If at least one change mapping to a major version is included, the major version needs to be incremented. In that case, the minor and patch versions are set to `0`. If there are no changes related to a major version, but changes related to a minor version are present, the minor version needs to be incremented while the patch version is set to `0`. Otherwise, only the patch version is incremented. Determining the version of the release is the responsibility of the person performing the release.
+The final list of changes from the [changelog](#changelog) informs the version of the release. If at least one change mapping to a major version is included, the major version needs to be incremented. In that case, the minor and patch versions are set to `0`. If there are no changes related to a major version, but changes related to a minor version are present, the minor version needs to be incremented while the patch version is set to `0`. Otherwise, only the patch version is incremented. Determining the version of the release is the responsibility of the person performing the release.
 
 The determined version of the release is used to create the [hotfix](#hotfix) or [release](#release) branch. For example, a major release from the previous version `v2.3.1` will create the `release/v3.0.0` branch.
 
@@ -149,9 +149,9 @@ You should follow these steps to create a release:
    2.2. Determine the next version string.
    2.3. Run the workflow. The workflow will create a PR from `dev` targeting `dev` with release related changes.
 3. Review the PR.
-   3.1. The PR will update the changelog, check that it has all expected entries in the appropriate sections and the determined version matches the changelog according to [SemVer](#Semantic-Versioning).
+   3.1. The PR will update the changelog, check that it has all expected entries in the appropriate sections and the determined version matches the changelog according to [SemVer](#semantic-versioning).
    3.2. The PR will update project version strings, ensure these are correct and match the expected version.
-   3.3. Refer to [Troubleshooting](#Troubleshooting) if anything is incorrect.
+   3.3. Refer to [Troubleshooting](#troubleshooting) if anything is incorrect.
 4. Merge the PR.
    4.1. On merging to `dev`, an automatic workflow is triggered that builds and publishes artifacts to the appropriate package manager (`crates.io` for Rust, `npm` for the WASM bindings), and creates a GitHub Release (only for `main` version releases of the core Rust library).
 5. For `main` version releases, merge the `dev` branch into the `main` branch.
@@ -162,13 +162,13 @@ You should follow these steps to create a release:
 
 Update the titles of the relevant PRs, then re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
 
-#### The changelog in the release PR is missing entries, has unrelated entries, or entries in the wrong section.
+#### The changelog in the release PR is missing entries, has unrelated entries, or entries in the wrong section
 
-Fix the [labels](#PR-Labels) on the relevant PRs, then re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
+Fix the [labels](#pr-labels) on the relevant PRs, then re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
 
 #### The release description in the release PR is missing or wrong
 
-Fix the issue description, milestone, and label according to the [release summaries guide](#Release-Summary) and re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
+Fix the issue description, milestone, and label according to the [release summaries guide](#release-summary) and re-run the workflow with the same parameters. The release PR will be updated with the new changelog.
 
 #### Features or code are missing from the release
 

diff --git a/docs/build/identity.rs/1.0-rc.1/docs/decentralized_identity.mdx b/docs/build/identity.rs/1.0-rc.1/docs/decentralized_identity.mdx
@@ -77,7 +77,7 @@ There is a growth in applications that generate Digital Twins for physical devic
 
 Security is a major barrier in advancing technologies that use IoT. Whether it is the smart devices in our own homes, or at a larger scale, the critical infrastructure of organizations and cities, security must be at the core. It is central to any globally-unifying identity solution. By integrating advanced research in cryptography and digital ledgers, and combining it with a scalable access and management system, security will become a core functionality of the systems we build. By using scalable device DIDs, integrating verification and reputation schemes, and allowing for transparent tamper-proof accountability, we begin to understand how we can future-proof the security of our systems, allowing us to start trusting the process, and not the patch.
 
-## One Framework. Any Identity.
+## One Framework. Any Identity
 
 :::note Framework
Original file line number	Diff line number	Diff line change
Expand Up		@@ -152,4 +152,4 @@ This is <Highlight color="#1877F2">Facebook blue</Highlight> !

		## AddToMetaMaskButton

		<AddToMetaMaskButton />
		<AddToMetaMaskButton />