✨ lint markdown and add CI (#382)

Author: ctcpip

.github/workflows/lintyMcLintface.yml

@@ -0,0 +1,15 @@
+name: 'Lint Markdown'
+
+on: [pull_request, push]
+
+permissions:
+  contents: read
+
+jobs:
+  lint:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+      - run: npm i
+      - run: npm test

.gitignore

@@ -0,0 +1,136 @@
+# Logs
+logs
+*.log
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+lerna-debug.log*
+.pnpm-debug.log*
+
+# Diagnostic reports (https://nodejs.org/api/report.html)
+report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
+
+# Runtime data
+pids
+*.pid
+*.seed
+*.pid.lock
+
+# Directory for instrumented libs generated by jscoverage/JSCover
+lib-cov
+
+# Coverage directory used by tools like istanbul
+coverage
+*.lcov
+
+# nyc test coverage
+.nyc_output
+
+# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
+.grunt
+
+# Bower dependency directory (https://bower.io/)
+bower_components
+
+# node-waf configuration
+.lock-wscript
+
+# Compiled binary addons (https://nodejs.org/api/addons.html)
+build/Release
+
+# Dependency directories
+node_modules/
+jspm_packages/
+
+# Snowpack dependency directory (https://snowpack.dev/)
+web_modules/
+
+# TypeScript cache
+*.tsbuildinfo
+
+# Optional npm cache directory
+.npm
+
+# Optional eslint cache
+.eslintcache
+
+# Optional stylelint cache
+.stylelintcache
+
+# Microbundle cache
+.rpt2_cache/
+.rts2_cache_cjs/
+.rts2_cache_es/
+.rts2_cache_umd/
+
+# Optional REPL history
+.node_repl_history
+
+# Output of 'npm pack'
+*.tgz
+
+# Yarn Integrity file
+.yarn-integrity
+
+# dotenv environment variable files
+.env
+.env.development.local
+.env.test.local
+.env.production.local
+.env.local
+
+# parcel-bundler cache (https://parceljs.org/)
+.cache
+.parcel-cache
+
+# Next.js build output
+.next
+out
+
+# Nuxt.js build / generate output
+.nuxt
+dist
+
+# Gatsby files
+.cache/
+# Comment in the public line in if your project uses Gatsby and not Next.js
+# https://nextjs.org/blog/next-9-1#public-directory-support
+# public
+
+# vuepress build output
+.vuepress/dist
+
+# vuepress v2.x temp and cache directory
+.temp
+.cache
+
+# vitepress build output
+**/.vitepress/dist
+
+# vitepress cache directory
+**/.vitepress/cache
+
+# Docusaurus cache and generated files
+.docusaurus
+
+# Serverless directories
+.serverless/
+
+# FuseBox cache
+.fusebox/
+
+# DynamoDB Local files
+.dynamodb/
+
+# TernJS port file
+.tern-port
+
+# Stores VSCode versions used for testing VSCode extensions
+.vscode-test
+
+# yarn v2
+.yarn/cache
+.yarn/unplugged
+.yarn/build-state.yml
+.yarn/install-state.gz
+.pnp.*

.markdownlint-cli2.jsonc

@@ -0,0 +1,9 @@
+{
+  "globs": [
+    "**/*.md"
+  ],
+  "ignores": [
+    ".github/**",
+    "node_modules/**"
+  ]
+}

.markdownlint.yml

@@ -0,0 +1,11 @@
+# for reference, see https://github.com/DavidAnson/markdownlint/blob/main/schema/.markdownlint.yaml
+
+# Default state for all rules
+default: true
+
+# MD013/line-length - Line length
+MD013: false
+
+# MD033/no-inline-html - Inline HTML
+MD033:
+  allowed_elements: ['kbd', 'sup']

.npmrc

@@ -0,0 +1 @@
+package-lock=false

docs/CHARTER.md

@@ -30,7 +30,7 @@ Express is made of many modules spread between three GitHub Orgs:
 
 Section Intentionally Left Blank
 
-## Section 2: Relationship with OpenJS Foundation CPC.
+## Section 2: Relationship with OpenJS Foundation CPC
 
 Technical leadership for the projects within the OpenJS Foundation is
 delegated to the projects through their project charters by the OpenJS
@@ -89,4 +89,4 @@ Section Intentionally Left Blank
 
 ## Section 5: Definitions
 
-Section Intentionally Left Blank
+Section Intentionally Left Blank

docs/GOVERNANCE.md

@@ -135,16 +135,17 @@ project for at least 6 months as a committer prior to the request. They should h
 helped with code contributions as well as triaging issues. They are also required to
 have 2FA enabled on both their GitHub and npm accounts.
 
-Any TC member or an existing captain on the **same** repo can nominate another committer 
-to the captain role. To do so, they should submit a PR to this document, updating the 
-**Active Project Captains** section (while maintaining the sort order) with the project 
+Any TC member or an existing captain on the **same** repo can nominate another committer
+to the captain role. To do so, they should submit a PR to this document, updating the
+**Active Project Captains** section (while maintaining the sort order) with the project
 name, the nominee's GitHub handle, and their npm username (if different).
-- Repos can have as many captains as make sense for the scope of work.
-- A TC member or an existing repo captain **on the same project** can nominate a new captain. 
+
+* Repos can have as many captains as make sense for the scope of work.
+* A TC member or an existing repo captain **on the same project** can nominate a new captain.
   Repo captains from other projects should not nominate captains for a different project.
 
-The PR will require at least 2 approvals from TC members and 2 weeks hold time to allow 
-for comment and/or dissent.  When the PR is merged, a TC member will add them to the 
+The PR will require at least 2 approvals from TC members and 2 weeks hold time to allow
+for comment and/or dissent.  When the PR is merged, a TC member will add them to the
 proper GitHub/npm groups.
 
 ### Active Projects and Captains
@@ -181,4 +182,4 @@ By making a contribution to this project, I certify that:
      personal information I submit with it, including my sign-off) is
      maintained indefinitely and may be redistributed consistent with
      this project or the open source license(s) involved.
-```
+```

docs/LTS-strategy.md

@@ -39,4 +39,4 @@
 
 ### Release calendar
 
-* There is a regular cadence of semver major releases (details TBD). However, if no breaking changes were introduced between the last semver major and the scheduled date of the release of the new one, the new semver major release is skipped.
+* There is a regular cadence of semver major releases (details TBD). However, if no breaking changes were introduced between the last semver major and the scheduled date of the release of the new one, the new semver major release is skipped.

docs/adr/290-using-caret-with-dependencies.md

@@ -13,6 +13,7 @@ Accepted
 - Express TC (@expressjs/express-tc)
 
 ## Context
+
 Historically, the Express project has avoided using the caret (`^`) in the `package.json` files for its own dependencies. This proposal aims to review whether this practice should continue or if adjustments are needed.
 
 **Why do we need this decision?**  
@@ -22,36 +23,44 @@ Clarifying the policy on using caret (`^`) helps to ensure consistency across th
 This decision aims to reduce the maintenance burden of frequently updating pinned dependencies.
 
 **Are there any existing issues/discussions/pull requests related to this?**  
+
 - [Discussion: Using caret (^) with our own dependencies #279](https://github.com/expressjs/discussions/issues/279)
 - [expressjs/express#6017 (comment)](https://github.com/expressjs/express/issues/6017)
 
 ## Decision
+
 We will adopt a policy where the caret (`^`) symbol is used for dependencies all dependencies.
 
 **What will be done?**  
+
 - Update the `package.json` files to use `^` for all dependencies (both prod and dev).
 
 **Note on `^` vs. `~`:**  
+
 - `^` allows updates to the most recent minor or patch version, offering greater flexibility and reducing the need for frequent manual updates. For example, `^1.2.3` will accept updates to `1.3.0`, `1.4.0`, but not `2.0.0`.
 - `~` is more conservative, only allowing updates to patch versions. For example, `~1.2.3` will accept updates to `1.2.4`, `1.2.5`, but not `1.3.0`. Some Node.js legacy versions only support this, like Node@0.8.
 
 **What will not be done?**  
+
 - We won't force to use `^` or `~` for any dependency if there is a reason to use a pinned version and it is properly documented.
 
 ## Rationale
 
 **Alternatives Considered:**
+
 - **Alternative:** Continue pinning all dependencies, including internal ones, to specific versions.  
 - **Reason for rejection:** This approach requires frequent updates and increases the maintenance burden, as each minor or patch update requires a new release.
 
 **Pros and Cons**:
 
 **Pros**:  
+
 - Reduces the number of PRs for updating our own dependencies.
 - Allows for quicker adoption of minor and patch updates within the Express ecosystem.
 - Users are still protected by lockfiles, mitigating the risk of regressions.
 
 **Cons**:  
+
 - There is still a risk of minor regressions from updates, even within internally managed dependencies.
 - Requires discipline in maintaining lockfiles to ensure stability for end users.
 
@@ -61,14 +70,17 @@ This decision strikes a balance between reducing maintenance effort and managing
 ## Consequences
 
 **Positive Impact**:  
+
 - Fewer manual updates required for internally managed dependencies.
 - Users benefit from improvements and fixes in internal packages more quickly.
 
 **Negative Impact**:  
+
 - Potential risk of regressions if an internal dependency introduces a breaking change in a minor update.
 - Users relying on strict version control may need to adjust their expectations when using our own dependencies.
 
 **Mitigations**:
+
 - Strong test coverage and CI checks will help catch potential issues early.
 - Clear communication in documentation and release notes to inform users of the updated dependency policy.
 - Ensure that we are following strict semver when releasing our own libraries.
@@ -79,7 +91,9 @@ This decision strikes a balance between reducing maintenance effort and managing
 - **Phase 2**: Review and adjust documentation to include the new policy on dependency versioning.
 
 ## References
+
 - [NPM semver documentation](https://docs.npmjs.com/cli/v6/using-npm/semver)
 
 ## Changelog
+
 - **[2024-10-22]**: @UlisesGascon - Initial draft of ADR for using caret (`^`) or tilde (`~`) with our own dependencies.

docs/adr/306-performance-wg.md

@@ -18,7 +18,7 @@ Express has traditionally taken a very lax approach to performance. Historically
 and lack of visibility around how changes impact performance. The goal of this working
 group is to centralize discussion so the whole ecosystem of packages can benefit from targeted performance work. The
 scope of this WG would be all active packages in the `expressjs`, `pillarjs` and `jshttp` orgs with an initial focus on
-the ones which are direct dependencies of `express` itself. 
+the ones which are direct dependencies of `express` itself.
 
 **Why do we need a working group?**
 
@@ -52,24 +52,24 @@ We will need to take a few actions to get this started:
 
 ### Relation to STF
 
-Lastly, this kicko-off work is being funded by the STF program. It is a part of our larger work around security
+Lastly, this kick-off work is being funded by the STF program. It is a part of our larger work around security
 improvements for the project. There are two parts of that program which fall under this WG's purview:
 
 1. Milestone 6: Monitor performance across Express and direct dependencies
-  - Owner: @wesleytodd
-  - Delivery Date: Dec 31, 2025
-  - Estimated Budget: €25,200
-2. Milestone 9: Improve performance for Express and critical dependencies
-  - Owner: @wesleytodd & @blakeembrey
-  - Delivery Date: Jun 30, 2026
-  - Estimated Budget: €46,200
+   - Owner: @wesleytodd
+   - Delivery Date: Dec 31, 2025
+   - Estimated Budget: €25,200
+1. Milestone 9: Improve performance for Express and critical dependencies
+   - Owner: @wesleytodd & @blakeembrey
+   - Delivery Date: Jun 30, 2026
+   - Estimated Budget: €46,200
 
 This funding does not mean the work can only be done by the owners, it just means that we are responsible for organizing
 and executing on the deliverables. This is our first attempt at doing a program like this, so feedback is welcome.
 
 ## References
 
-- https://github.com/expressjs/express/pull/6129
-- https://github.com/expressjs/express/issues/5998
+- <https://github.com/expressjs/express/pull/6129>
+- <https://github.com/expressjs/express/issues/5998>
 - open-telemetry/opentelemetry-js-contrib#2437
 - openjs-foundation/infrastructure#5