Upgrade to Docusarus 3.4.0, Update Nav Bar (#616)

* Upgrade to docusarus 3.4.0

* adjust the nav bar

* fix build

* fix mdx

* Add components

* finish upgrade to 3.4

* bump node version

* add placeholders

* add placeholders

* fix deprecated actions

* upgrade actions

* upgrade modules

Author: osterman

.github/actions/build-website/action.yml

@@ -24,14 +24,14 @@ runs:
   steps:
     # https://github.com/marketplace/actions/configure-aws-credentials-action-for-github-actions
     - name: Configure AWS Credentials
-      uses: aws-actions/configure-aws-credentials@v1
+      uses: aws-actions/configure-aws-credentials@v4
       with:
         aws-region: ${{ inputs.aws_region }}
         role-to-assume: ${{ inputs.iam_role_arn }}
         role-session-name: ${{ inputs.iam_role_session_name }}
 
     - name: Checkout Repository
-      uses: actions/checkout@v3
+      uses: actions/checkout@v4
       with:
         fetch-depth: 0
 
@@ -41,7 +41,7 @@ runs:
         node-version-file: ".nvmrc"
 
     - name: "Checkout 'terraform-aws-components' Repository"
-      uses: actions/checkout@v3
+      uses: actions/checkout@v4
       with:
         fetch-depth: 1
         repository: cloudposse/terraform-aws-components

.github/workflows/website-deploy-preview.yml

@@ -43,32 +43,32 @@ jobs:
     steps:
       # https://github.com/marketplace/actions/configure-aws-credentials-action-for-github-actions
       - name: Configure AWS Credentials
-        uses: aws-actions/configure-aws-credentials@v1
+        uses: aws-actions/configure-aws-credentials@v4
         with:
           aws-region: ${{ env.AWS_REGION }}
           role-to-assume: ${{ env.IAM_ROLE_ARN }}
           role-session-name: ${{ env.IAM_ROLE_SESSION_NAME }}
 
       - name: Checkout Repository
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
         with:
           fetch-depth: 0
 
       - name: Setup Node
-        uses: actions/setup-node@v3
+        uses: actions/setup-node@v4
         with:
           node-version-file: ".nvmrc"
 
       - name: "Checkout 'terraform-aws-components' Repository"
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
         with:
           fetch-depth: 1
           repository: cloudposse/terraform-aws-components
           ref: main
           path: tmp/components/terraform-aws-components
 
       - name: "Setup Python"
-        uses: actions/setup-python@v4
+        uses: actions/setup-python@v5
         with:
           python-version: '3.10'
 

.github/workflows/website-deploy-staging-preview.yml

@@ -34,7 +34,7 @@ jobs:
 
     steps:
       - name: Checkout Repository
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
         with:
           fetch-depth: 0
 

.github/workflows/website-deploy-staging-release.yml

@@ -33,7 +33,7 @@ jobs:
 
     steps:
       - name: Checkout Repository
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
         with:
           fetch-depth: 0
 

.nvmrc

@@ -1 +1 @@
-v19.4.0
+v21.7.3

Makefile

@@ -8,7 +8,7 @@ all: real-clean build
 	@exit 0
 
 deps:
-	npm install --only=production
+	npm install
 
 .PHONY: build
 
@@ -23,6 +23,7 @@ build: deps
 build-production: build
 	@exit 0
 
+up: start
 start:
 	npm start
 
@@ -33,3 +34,6 @@ real-clean:
 	rm -fr .docusaurus && \
     rm -fr build && \
     rm -fr node_modules
+
+lint:
+	npx docusaurus-mdx-checker --cwd docs

docs/best-practices/docker-best-practices.md

@@ -10,7 +10,9 @@ Inheritance is when you use `FROM some-image:1.2.3` (vs `FROM scratch`) in a `Do
 Try to leverage the same base image in as many of your images as possible for faster `docker pulls`.
 
 :::info
-- <https://docs.docker.com/engine/reference/builder/#from>
+
+- https://docs.docker.com/engine/reference/builder/#from
+
 :::
 
 ## Multi-stage Builds
@@ -21,8 +23,8 @@ There are two ways to leverage multi-stage builds:
 2. *Multiple-Inheritance* We like to think of "multi-stage builds" as a mechanism for "multiple inheritance" as it relates to docker images. While not technically the same thing, using multi-stage images makes it possible to `COPY --from=other-image` to keep things very DRY.
 
 :::info
-- <https://docs.docker.com/develop/develop-images/multistage-build/>
-- <https://blog.alexellis.io/mutli-stage-docker-builds/>
+- https://docs.docker.com/develop/develop-images/multistage-build/
+- https://blog.alexellis.io/mutli-stage-docker-builds/
 :::
 
 ## Use Scratch Base Image
@@ -41,7 +43,7 @@ When using self-hosted GitHub Actions Runners in an AWS environment, however, we
 
 The following example demonstrates how to configure the [cloudposse/github-action-docker-build-push](https://github.com/cloudposse/github-action-docker-build-push) action to use ECR as the remote cache storage backend:
 
-  ```diff
+```diff
     - name: Build
       id: build
       uses: cloudposse/github-action-docker-build-push@main

docs/best-practices/editor-config.md

@@ -67,11 +67,11 @@ indent_size = 4
 
 ## Editor Plugins
 
-Find all plugins here: <http://editorconfig.org/#download>
+Find all plugins here: http://editorconfig.org/#download
 
 - [Vim](https://github.com/editorconfig/editorconfig-vim#readme)
 - [Visual Studio](https://marketplace.visualstudio.com/items?itemName=EditorConfigTeam.EditorConfig)
 
 ## References
 
-- <http://editorconfig.org/>
+- http://editorconfig.org/

docs/best-practices/github-feature-branches.md

@@ -30,7 +30,7 @@ A _Pull Request_ allows many things to happen:
 - **Description**: A long description that details **_What_** was changed, **_Why_** it was deemed necessary, and any other **_References_** that might be useful (E.g. Jira ticket)
 - **Comments**: let anyone provide arbitrary feedback viewable by everyone.
 - **Diffs**: show what changed between this feature and the current master branch
-- **Formal Code Review Process:** let multiple people contribute to the code review process by submitting comments on a line-by-line basis. Having these code reviews formally documented serves as an excellent teaching tool. Over time, the reviews become faster and faster as developers learn what is expected. {{< img src="/assets/9df4fad-image_2.png" title="Example of Code Review" >}}
+- **Formal Code Review Process:** let multiple people contribute to the code review process by submitting comments on a line-by-line basis. Having these code reviews formally documented serves as an excellent teaching tool. Over time, the reviews become faster and faster as developers learn what is expected. ![Example of Code Review](/assets/9df4fad-image_2.png)
 - **Merging**: Once the PR is approved, the developer can squash and merge their code into the master branch. Squashing allows the master branch to have a very clean commit history where every commit corresponds to a PR. ![Example of Merging](/assets/2b3e7eb-image_4.png)
 - **Clean Commit History**: means that every change to the master branch is documented and justified. No one is sneaking in changes. ![Example of Clean Commit History](/assets/b3dae79-image_5.png)
 - **History of Features** and when they were added ![History of Features](/assets/f9a3727-image_7.png)

docs/best-practices/github-pull-requests.md

@@ -25,7 +25,7 @@ Once that is happy, push the rebased changes back to the origin.
 git push origin newfeature -f
 ```
 
-Then follow these instructions once you're ready: <https://help.github.com/articles/creating-a-pull-request/>
+Then follow these instructions once you're ready: https://help.github.com/articles/creating-a-pull-request/
 
 ## Pull Request Template
 
@@ -45,5 +45,5 @@ Use the following markdown template to describe the Pull Request.
 **Pro Tip:** Use a `.github/pull_request_template.md` file to automatically populate this template when creating new Pull Requests.
 
 :::info
-<https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/>
+https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/
 :::

docs/best-practices/project-management-managers-vs-makers.md

@@ -12,5 +12,6 @@ Developers (Makers) and Managers work differently.
 
 Interrupts are costly for developers and therefore the business.
 
-<http://www.paulgraham.com/makersschedule.html>
+http://www.paulgraham.com/makersschedule.html
+
  (Paul Graham - YCombinator Founder)

docs/best-practices/terraform-tips-tricks.md

@@ -62,8 +62,8 @@ resource "aws_s3_bucket" "assets" {
 For an example of how we use it, check out our [`terraform-aws-s3-log-storage`](https://github.com/cloudposse/terraform-aws-s3-log-storage) module.
 
 :::info
-- <https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html>
-- <https://www.terraform.io/docs/providers/aws/r/s3_bucket.html#using-object-lifecycle>
+- https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html
+- https://www.terraform.io/docs/providers/aws/r/s3_bucket.html#using-object-lifecycle
 :::
 
 

docs/category/README.md

@@ -0,0 +1,6 @@
+## Placeholder Categories
+
+Due to an issue with the Docusaurus build process, placeholder directories and files were created for the following categories:
+
+- `how-to`
+- `legacy`