Replace mdspell, bump deps (#591)

RichardSlater · web-flow · commit b9fb0bad3ba0 · 2025-08-04T09:40:48.000+01:00
* fix(): replace mdspell with cspell

* fix(): linter failings

* fix(): typo

* fix(): lf at eof
diff --git a/.gitignore b/.gitignore
@@ -24,4 +24,4 @@ yarn-debug.log*
 yarn-error.log*
 .vscode/*
 .vs/*
-.env
+.env
diff --git a/Dockerfile b/Dockerfile
@@ -15,4 +15,4 @@ FROM gcr.io/distroless/nodejs:20
 COPY --from=build-env /app /app
 WORKDIR /app
 EXPOSE 3000
-CMD ["node_modules/@docusaurus/core/bin/docusaurus.js", "start", "--host", "0.0.0.0", "--no-open"]
+CMD ["node_modules/@docusaurus/core/bin/docusaurus.js", "start", "--host", "0.0.0.0", "--no-open"]
diff --git a/README.md b/README.md
@@ -4,7 +4,7 @@ This repository contains the documentation for the Ensono Stacks platform.
 The live site is hosted at [https://stacks.ensono.com](https://stacks.ensono.com).
 
 This microsite is built using [Docusaurus 2](https://v2.docusaurus.io/), a modern static website generator.
-You can view their documentation [here](https://v2.docusaurus.io/docs/).
+You can [view their documentation](https://v2.docusaurus.io/docs/).
 
 ## Making changes
 
diff --git a/cspell.json b/cspell.json
@@ -0,0 +1,10 @@
+{
+    "version": "0.2",
+    "words": [
+      "Ensono",
+      "unwelcomed",
+      "amidostacks",
+      "humaning",
+      "fuzzies"
+    ]
+}
diff --git a/docs/getting_started/azure-container-app/ACA.md b/docs/getting_started/azure-container-app/ACA.md
@@ -167,7 +167,7 @@ Con's
 We recommend implementing Option 2: Container App Environment deployment via Infrastructure pipeline and Container App deployment via Application pipeline. This approach provides the flexibility to manage infrastructure and application deployments separately while optimizing the deployment process for Azure Container Apps.
 This recommendation will result in a more streamlined deployment process, eliminating unnecessary Container App revisions and allowing for tighter integration between application builds and deployments.
 
-However, it's important to note that this approach will require additional effort in managing separate Terraform configurations for each Container App. To mitigate this challenge, we will utilize the existing Azure Container Apps Terraform module developed by Ensono, which is available [here](https://registry.terraform.io/modules/Ensono/aca/azurerm/latest).
+However, it's important to note that this approach will require additional effort in managing separate Terraform configurations for each Container App. To mitigate this challenge, we will utilize the existing Azure Container Apps [Terraform module developed by Ensono](https://registry.terraform.io/modules/Ensono/aca/azurerm/latest).
 
 This pre-built module will help reduce duplication and ease maintenance across multiple Container Apps, standardizing our Container App deployments and reducing the overhead of managing individual Terraform configurations.
 By leveraging this existing module in our recommended approach, we can achieve a more efficient and manageable deployment strategy for our Azure Container Apps while maintaining the flexibility to evolve both infrastructure and applications independently.
diff --git a/docs/getting_started/logger/winston.md b/docs/getting_started/logger/winston.md
@@ -129,6 +129,6 @@ For more information on log level severity please refer to the [log levels](http
 
 ### Other resources
 
-Documentation for Winston can be found [here](https://github.com/winstonjs/winston).
+[Documentation for Winston](https://github.com/winstonjs/winston).
 
 </details>
diff --git a/docs/getting_started/setup.md b/docs/getting_started/setup.md
@@ -40,7 +40,7 @@ yarn global add nx
 
 #### Node
 
-We recommend using the latest LTS version of Node, you can find the latest LTS version [here](https://nodejs.org/en/).
+We recommend using the latest [LTS version of Node](https://nodejs.org/en/).
 
 ### Get Started
 
diff --git a/docs/infrastructure/aws/pipelines/github_actions.md b/docs/infrastructure/aws/pipelines/github_actions.md
@@ -15,7 +15,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl';
 
 The pipeline will automate provisioning and updating the core infrastructure in AWS. This page assumes you have already completed the steps on the [core infrastructure page](../core_infrastructure.md).
 
-The AWS infrastructure source code can be found [here](https://github.com/Ensono/stacks-infrastructure-eks).
+The AWS infrastructure [source code](https://github.com/Ensono/stacks-infrastructure-eks).
 
 ## Pipeline Diagram
 
@@ -31,7 +31,7 @@ The AWS infrastructure source code can be found [here](https://github.com/Ensono
 
 ### Environment Secrets
 
-Environment secrets will need creating for storing some sensitive variables to be used by the pipeline. Instructions for creating a environment secrets can be found [here](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment#environment-secrets).
+Environment secrets will need creating for storing some sensitive variables to be used by the pipeline. Instructions for creating a [environment secrets](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment#environment-secrets).
 
 Add the following secrets:
 
@@ -52,6 +52,6 @@ Where possible, the Stacks CLI will have populated the correct values in the pip
 
 ### Create the pipeline
 
-Stacks generates the GitHub Actions workflow file in the directory expected by GitHub Actions, `.github/workflows`. Committing this file to the `main` branch of a GitHub repository will "create" the pipeline. Instructions for viewing the results can be found [here](https://docs.github.com/en/actions/writing-workflows/quickstart#viewing-your-workflow-results)
+Stacks generates the GitHub Actions workflow file in the directory expected by GitHub Actions, `.github/workflows`. Committing this file to the `main` branch of a GitHub repository will "create" the pipeline. Instructions for viewing [the results](https://docs.github.com/en/actions/writing-workflows/quickstart#viewing-your-workflow-results)
 
 <HideNavigation next />
diff --git a/docs/infrastructure/azure/pipelines/azure_devops.md b/docs/infrastructure/azure/pipelines/azure_devops.md
@@ -15,7 +15,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl';
 
 The pipeline will automate provisioning and updating the core infrastructure in Azure. This page assumes you have already completed the steps on the [core infrastructure page](../core_infrastructure.md).
 
-The Azure infrastructure source code can be found [here](https://github.com/Ensono/stacks-infrastructure-aks).
+The Azure [infrastructure source code](https://github.com/Ensono/stacks-infrastructure-aks).
 
 ## Pipeline Diagram
 
@@ -31,7 +31,7 @@ The Azure infrastructure source code can be found [here](https://github.com/Enso
 
 ### Variable groups
 
-Variable groups will need creating for storing Azure Credentials to be used with the pipeline. Instructions for creating a variable group can be found [here](https://docs.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=azure-devops&tabs=classic#create-a-variable-group).
+Variable groups will need creating for storing Azure Credentials to be used with the pipeline. Instructions for creating a [variable group](https://docs.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=azure-devops&tabs=classic#create-a-variable-group).
 
 Create a variable group called `azure-sp-creds`, add a description and make sure the **Allow access to all pipelines** option is checked. Add the following variables using the Service Connection details from [bootstrapping the Azure tenant](../core_infrastructure.md#bootstrap-the-azure-tenant):
 
diff --git a/docs/infrastructure/introduction.md b/docs/infrastructure/introduction.md
@@ -20,7 +20,7 @@ All Ensono Stacks workloads require initial configuration of the cloud provider
 
 All infrastructure tooling is done with [Terraform](https://www.terraform.io/), as a method for implementing infrastructure as code. Terraform uses workspaces as the main mechanism of segregating states.
 
-All the modules used by Ensono Stacks are documented and maintained [here](https://github.com/Ensono/stacks-terraform)
+All the modules used by Ensono Stacks are [documented and maintained](https://github.com/Ensono/stacks-terraform)
 
 <HideNavigation next />
 <HideNavigation prev />
diff --git a/docs/module_federation/nextjs_plugin.md b/docs/module_federation/nextjs_plugin.md
@@ -54,7 +54,7 @@ yarn global add nx
 
 #### Node
 
-We recommend using the latest LTS version of Node, you can find the latest LTS version [here](https://nodejs.org/en/).
+We recommend using the latest LTS version of Node, you can find the [latest LTS version](https://nodejs.org/en/).
 
 ### Get Started
 
diff --git a/docs/testing/testing_overview.md b/docs/testing/testing_overview.md
@@ -17,6 +17,7 @@ keywords:
 Building testing frameworks from scratch requires a lot of boilerplate code. It is also hard to know how to get started without examples.
 
 To ensure the quality and reliability of your software projects, Ensono Stacks includes a range of integrated testing frameworks. These frameworks are designed to be easily bootstrapped and customized to fit your specific project needs. The tests integrated within each stack is summarised in this table:
+
 | Testing Type           | .Net | Java | Frontend/NX | Data |
 |------------------------|------|------|-------------|------|
 | Unit                   | ✔    | ✔    | ✔          | ✔    |
@@ -60,7 +61,7 @@ Examples:
 
 ### Performance Testing
 
-Performance testing ensures that your application can handle the expected load and perform well under stress. Ensono Stacks uses [Gatling](https://gatling.io/) for performance testing.  Further information can be found [here.](./performance_testing_gatling.md)
+Performance testing ensures that your application can handle the expected load and perform well under stress. Ensono Stacks uses [Gatling](https://gatling.io/) for [performance testing](./performance_testing_gatling.md).
 
 ### UI Testing
 
@@ -93,9 +94,9 @@ Contract testing ensures that the interactions between services are working as e
 
 Ensono Stacks .NET includes comprehensive functional and unit tests for ServiceBus operations to ensure the correct handling of topics, queues, and messages.  
 
-The GitHub repository folder containing the ServiceBus unit tests can be found [here](https://github.com/Ensono/stacks-dotnet/tree/master/src/shared/xxENSONOxx.xxSTACKSxx.Shared.Messaging.Azure.ServiceBus.Tests).  These tests ensure that the various components of the ServiceBus, such as validators, serializers, routers, listeners, and custom processors, function correctly and handle different scenarios as expected.
+The GitHub repository folder containing the [ServiceBus unit tests](https://github.com/Ensono/stacks-dotnet/tree/master/src/shared/xxENSONOxx.xxSTACKSxx.Shared.Messaging.Azure.ServiceBus.Tests).  These tests ensure that the various components of the ServiceBus, such as validators, serializers, routers, listeners, and custom processors, function correctly and handle different scenarios as expected.
 
-Functional tests can be found in the GitHub repository folder [here](https://github.com/Ensono/stacks-dotnet/tree/master/src/func-cosmosdb-worker/src/tests/Functional/xxENSONOxx.xxSTACKSxx.Worker.FunctionalTests/Tests).  Key areas of coverage include:
+Functional tests can be found in the [GitHub repository folder](https://github.com/Ensono/stacks-dotnet/tree/master/src/func-cosmosdb-worker/src/tests/Functional/xxENSONOxx.xxSTACKSxx.Worker.FunctionalTests/Tests).  Key areas of coverage include:
 
 - Adding messages to the queue
 - Checking the existence of topics
@@ -108,7 +109,7 @@ Ensono Stacks .NET includes unit and integration tests for CosmosDB operations t
 
 - Unit tests for verifying the repository implementation and its functionality using a mock repository.  The unit test example are in the CosmosDbMenuRepositoryTests.cs in this repository [folder](https://github.com/Ensono/stacks-dotnet/blob/master/src/cqrs/src/api/xxENSONOxx.xxSTACKSxx.Infrastructure.UnitTests/). 
 
-- Integration tests for CosmosDB Document Storage, validating communication with CosmosDB, data encoding/decoding, and various search operations, including tests for single/multiple fields, ordering, partition keys, and SQL queries.  The integration tests are in the repository folder [here](https://github.com/Ensono/stacks-dotnet/tree/master/src/cqrs/src/api/xxENSONOxx.xxSTACKSxx.Infrastructure.IntegrationTests/CosmosDb/Integration). 
+- Integration tests for CosmosDB Document Storage, validating communication with CosmosDB, data encoding/decoding, and various search operations, including tests for single/multiple fields, ordering, partition keys, and SQL queries.  The integration tests are in the [repository folder](https://github.com/Ensono/stacks-dotnet/tree/master/src/cqrs/src/api/xxENSONOxx.xxSTACKSxx.Infrastructure.IntegrationTests/CosmosDb/Integration). 
 
 ### SonarCloud
 
diff --git a/docs/workloads/azure/backend/java/infrastructure_java.md b/docs/workloads/azure/backend/java/infrastructure_java.md
@@ -22,7 +22,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl';
 This page present the high level design of the reference implementation of the Java Ensono Stacks
 application which is based on Spring Boot REST API.
 
-**This page assumes that the core infrastructure has already been provisioned. Instructions and additional information on the core infrastructure can be found [here](docs/infrastructure/azure/core_infrastructure.md)**
+**This page assumes that the core infrastructure has already been provisioned. Instructions and additional information on the [core infrastructure](docs/infrastructure/azure/core_infrastructure.md)**
 
 Both the diagram and resource list below are for a single environment. By default, the pipeline template will create two environments (dev and prod).
 
diff --git a/docs/workloads/azure/backend/java/pipeline_java.md b/docs/workloads/azure/backend/java/pipeline_java.md
@@ -28,7 +28,7 @@ Where possible, we are creating reusable steps ([stacks-pipeline-templates](http
 
 ### Variable group
 
-A variable group will need creating for storing application variables to be used with the pipeline. Instructions for creating a variable group can be found [here](https://docs.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=azure-devops&tabs=classic#create-a-variable-group). Give the variable group a name and description and make sure the **Allow access to all pipelines** option is checked.
+A variable group will need creating for storing application variables to be used with the pipeline. Instructions for creating a [variable group](https://docs.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=azure-devops&tabs=classic#create-a-variable-group). Give the variable group a name and description and make sure the **Allow access to all pipelines** option is checked.
 
 Add the following variables:
 
diff --git a/docs/workloads/azure/backend/java/quickstart_java.md b/docs/workloads/azure/backend/java/quickstart_java.md
@@ -42,7 +42,7 @@ It uses an Azure **CosmosDB** database to store the example application data. So
 
 :::note
 For running on a local environment you can use the [Cosmos DB emulator](/docs/workloads/azure/backend/java/setting_up_cosmos_db_locally_java) (CosmosDB Emulator has a known fixed key). There is no need for CosmosDB for the simple web API implementation (1.i above) as there is no persistence layer in it.
-For further info please follow the [link](https://docs.microsoft.com/en-us/azure/cosmos-db/local-emulator?tabs=ssl-netstd21).
+[Further information is available from Microsoft directly](<https://docs.microsoft.com/en-us/azure/cosmos-db/local-emulator?tabs=ssl-netstd21>).
 :::
 
 Set the cosmosdb URI, databaseName and key in main application configuration file (`application.yml`) using the values coming from the CosmosDB Emulator UI.
diff --git a/docs/workloads/azure/backend/java/setting_up_cosmos_db_locally_java.md b/docs/workloads/azure/backend/java/setting_up_cosmos_db_locally_java.md
@@ -21,7 +21,7 @@ import TabItem from '@theme/TabItem';
 The Azure CosmosDB Emulator provides a local environment that emulates the Azure Cosmos DB
 service for development purposes. Using the Azure CosmosDB Emulator, you can develop and test
 your application locally, without creating an Azure subscription or incurring any costs.
-Latest instruction can be found in [here](https://docs.microsoft.com/en-us/azure/cosmos-db/local-emulator?tabs=cli%2Cssl-netstd21)
+[Latest instruction](https://docs.microsoft.com/en-us/azure/cosmos-db/local-emulator?tabs=cli%2Cssl-netstd21)
 
 ### Using the Cosmos DB Emulator to run the database locally
 
diff --git a/docs/workloads/azure/backend/netcore/infrastructure_aws_netcore.md b/docs/workloads/azure/backend/netcore/infrastructure_aws_netcore.md
@@ -24,8 +24,6 @@ This page present the high level design of the reference implementation of the .
 
 <ResponsivePlayer url='https://www.youtube.com/watch?v=G8FW-djEDDY' />
 
-<!-- **This page assumes that the core infrastructure has already been provisioned. Instructions and additional information on the core infrastructure can be found [here](../../../../infrastructure/aws/core_infrastructure.md)** -->
-
 Both the diagram and resource list below are for a single environment.
 
 ### Diagram
diff --git a/docs/workloads/azure/backend/netcore/infrastructure_netcore.md b/docs/workloads/azure/backend/netcore/infrastructure_netcore.md
@@ -25,7 +25,7 @@ This page present the high level design of the reference implementation of the .
 
 <ResponsivePlayer url='https://www.youtube.com/watch?v=6ND-8YVohT4' />
 
-**This page assumes that the core infrastructure has already been provisioned. Instructions and additional information on the core infrastructure can be found [here](../../../../infrastructure/azure/core_infrastructure.md)**
+**This page assumes that the core infrastructure has already been provisioned. Instructions and additional information on the [core infrastructure](../../../../infrastructure/azure/core_infrastructure.md)**
 
 Both the diagram and resource list below are for a single environment.
 
diff --git a/docs/workloads/azure/backend/netcore/pipeline_gha_netcore.md b/docs/workloads/azure/backend/netcore/pipeline_gha_netcore.md
@@ -36,7 +36,7 @@ The pipeline will automate provisioning and updating the .NET REST API with CQRS
 
 A variable file located at `.github/workflows/ci-env.yml` will contain the majority of the variables required for the pipeline. **This file should be manually checked and updated where required before first deployment**. If the project was generated using the Stacks CLI then the file will be updated with the information provided.
 
-Environment secrets will need creating for storing some sensitive variables to be used by the pipeline. Instructions for creating a environment secrets can be found [here](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment#environment-secrets).
+Environment secrets will need creating for storing some sensitive variables to be used by the pipeline. Instructions for [creating a environment secrets](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment#environment-secrets).
 
 Add the following secrets:
 
@@ -53,4 +53,4 @@ Add the following secrets:
 
 ### Creating the pipeline
 
-Stacks generates the GitHub Actions workflow file in the directory expected by GitHub Actions, `.github/workflows`. Committing this file to the `main` branch of a GitHub repository will "create" the pipeline. Instructions for viewing the results can be found [here](https://docs.github.com/en/actions/writing-workflows/quickstart#viewing-your-workflow-results)
+Stacks generates the GitHub Actions workflow file in the directory expected by GitHub Actions, `.github/workflows`. Committing this file to the `main` branch of a GitHub repository will "create" the pipeline. Instructions for [viewing the results](https://docs.github.com/en/actions/writing-workflows/quickstart#viewing-your-workflow-results)
diff --git a/docs/workloads/azure/backend/netcore/pipeline_netcore.md b/docs/workloads/azure/backend/netcore/pipeline_netcore.md
@@ -36,7 +36,7 @@ The pipeline will automate provisioning and updating the .NET REST API with CQRS
 
 A variable file located at `build/azDevOps/azure/ci-vars.yml` will contain the majority of the variables required for the pipeline. **This file should be manually checked and updated where required before first deployment**. If the project was generated using the Stacks CLI then the file will be updated with the information provided.
 
-Variable groups will need creating for storing some sensitive variables to be used by the pipeline. Instructions for creating a variable group can be found [here](https://docs.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=azure-devops&tabs=classic#create-a-variable-group). Two variable groups are used by default, one for Azure credentials and one for any application specific variables.
+Variable groups will need creating for storing some sensitive variables to be used by the pipeline. Instructions for [creating a variable group](https://docs.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=azure-devops&tabs=classic#create-a-variable-group). Two variable groups are used by default, one for Azure credentials and one for any application specific variables.
 
 #### Azure Credentials
 
diff --git a/docs/workloads/azure/backend/netcore/testing/provider_contract_testing.md b/docs/workloads/azure/backend/netcore/testing/provider_contract_testing.md
diff --git a/docs/workloads/azure/data/getting_started/requirements_data_azure.md b/docs/workloads/azure/data/getting_started/requirements_data_azure.md
diff --git a/docs/workloads/common/backend/java/ide_java.md b/docs/workloads/common/backend/java/ide_java.md
diff --git a/package-lock.json b/package-lock.json
diff --git a/package.json b/package.json
