chore(deps): upgrade dependencies for Astro 7 (DOCSDEV-75)

astro.config.mjs

@@ -1,5 +1,6 @@
 import { defineConfig } from 'astro/config'
 import starlight from '@astrojs/starlight'
+import { unified } from '@astrojs/markdown-remark'
 import starlightLinksValidator from 'starlight-links-validator'
 import starlightFullViewMode from 'starlight-fullview-mode'
 
@@ -13,6 +14,9 @@ export default defineConfig({
   adapter: netlify(),
   site: 'https://interledger.org',
   base: '/developers',
+  markdown: {
+    processor: unified()
+  },
   integrations: [
     starlight({
       title: 'Interledger',

eslint.config.js

@@ -14,6 +14,7 @@ export default defineConfig([
   },
   tseslint.configs.recommended,
   eslintPluginAstro.configs.recommended,
+  eslintPluginAstro.configs['flat/jsx-a11y-recommended'],
   globalIgnores([
     'dist',
     '.astro',

package.json

@@ -11,34 +11,35 @@
     "lint": "prettier --check '**/*.{js,mjs,ts,tsx,json,md,mdx,astro}' && eslint --max-warnings=0 ."
   },
   "dependencies": {
-    "@astrojs/mdx": "^5.0.6",
-    "@astrojs/netlify": "^7.0.7",
-    "@astrojs/node": "^10.1.2",
-    "@astrojs/starlight": "^0.39.2",
-    "@interledger/docs-design-system": "^0.13.0",
-    "@linear/sdk": "^82.0.0",
-    "@netlify/blobs": "^10.7.4",
-    "@netlify/functions": "^5.2.0",
+    "@astrojs/markdown-remark": "^7.3.0",
+    "@astrojs/mdx": "^8.0.0",
+    "@astrojs/netlify": "^8.2.5",
+    "@astrojs/starlight": "^0.42.0",
+    "@interledger/docs-design-system": "^0.14.0",
+    "@linear/sdk": "^92.0.0",
+    "@netlify/blobs": "^11.0.2",
+    "@netlify/functions": "^6.0.0",
     "@types/showdown": "^2.0.6",
-    "astro": "~6.3.8",
-    "html-to-text": "^10.0.0",
-    "markdown-it": "^14.2.0",
-    "node-html-parser": "^7.1.0",
-    "sharp": "^0.34.5",
+    "astro": "~7.2.10",
+    "html-to-text": "^10.0.1",
+    "markdown-it": "^15.0.1",
+    "node-html-parser": "^9.0.2",
+    "sharp": "^0.35.4",
     "showdown": "^2.1.0",
     "starlight-fullview-mode": "^0.2.6",
-    "starlight-links-validator": "^0.24.0"
+    "starlight-links-validator": "^0.26.0"
   },
   "devDependencies": {
     "@eslint/js": "^10.0.1",
-    "@typescript-eslint/parser": "^8.59.0",
-    "astro-eslint-parser": "^1.4.0",
-    "eslint": "^10.2.1",
+    "@typescript-eslint/parser": "^8.69.0",
+    "astro-eslint-parser": "^3.1.0",
+    "eslint": "^10.9.1",
     "eslint-config-prettier": "^10.1.8",
-    "eslint-plugin-astro": "^1.7.0",
-    "globals": "^17.5.0",
-    "prettier": "^3.8.3",
+    "eslint-plugin-astro": "^3.1.0",
+    "eslint-plugin-jsx-a11y": "^6.10.2",
+    "globals": "^17.11.0",
+    "prettier": "^3.9.6",
     "prettier-plugin-astro": "^0.14.1",
-    "typescript-eslint": "^8.59.0"
+    "typescript-eslint": "^8.69.0"
   }
 }

src/content/blog/2018-10-03-interledger-how-to-interconnect-all-blockchains-and-value-networks.md

@@ -12,7 +12,7 @@ tags:
   - Interledger Protocol
 ---
 
-*By* [_Evan Schwartz_](https://www.linkedin.com/in/evanmarkschwartz/) *and* [_Vanessa Pestritto_](https://www.linkedin.com/in/vanessaalexandra/)
+_By_ [_Evan Schwartz_](https://www.linkedin.com/in/evanmarkschwartz/) _and_ [_Vanessa Pestritto_](https://www.linkedin.com/in/vanessaalexandra/)
 
 Interledger was born out of a project to build a [blockchain-agnostic smart contracts](https://medium.com/coil/codius-smart-contracts-made-from-containers-b3b16c3e3890) platform. A key challenge was neutrality: how could a decentralized app buy resources like storage and computing, without being tied to a specific blockchain? Across the internet, apps and services face a similar issue of how to directly monetize without relying on a single cryptocurrency, a proprietary network like Visa or PayPal, or a monolithic platform like Apple. Interledger was designed to answer the question:
 
@@ -62,7 +62,7 @@ Interledger uses a [“forward-and-backward” packet flow](https://interledger
 
 ![Diagram showing the “forward-and-backward” packet flow](/developers/img/blog/2018-10-03/packet-flow.webp)
 
-- Prepare packets travel from the sender to the receiver (the “forward” part) and represent a commitment to pay, *if and only if* the connector presents proof that the receiver was paid.
+- Prepare packets travel from the sender to the receiver (the “forward” part) and represent a commitment to pay, _if and only if_ the connector presents proof that the receiver was paid.
 - Fulfill packets include proof that the receiver was paid and are relayed by connectors back to the sender (the “backward” part). Only the receiver could generate the correct proof, which is a simple preimage of a hash. The sender knows with certainty when the money has arrived, no matter what path the packet has taken through the network of connectors. If a packet is misrouted or dropped, the sender will never get the Fulfill and the money will never leave their account.
 - Reject packets are returned by the receiver if they do not want the Prepare packet or the packet does not pass one of the receiver’s checks. Connectors may also return Reject packets if the Prepare expires before the Fulfill is returned. Note that the sender can retry rejected packets, because they haven’t sent the money yet, and [higher-level protocols](https://medium.com/interledger-blog/streaming-money-and-data-over-ilp-fabd76fc991e) built on top of Interledger handle retries automatically.
 

src/content/blog/2019-01-23-thoughts-on-scaling-interledger-connectors.md

@@ -35,7 +35,7 @@ This set of features meant that we could support a single protocol for both clie
 
 Interledger Service Providers (ILSPs) need to run multiple instances of the connector in order to process large volumes of Interledger packets. Unfortunately, this is difficult to do today, arguably because of BTP and its use of WebSockets.
 
-Current ILSPs that run multiple connectors configure different WebSocket URLs and ILP addresses for each instance. As a result, peering with another ILSP requires configuring each connector with *all* of the URLs and ILP addresses of the peer’s connectors (n² connections). This complicates configuring connectors, exposes an ILSP’s internal network configuration to their peers (a potential security concern), and prevents “autoscaling” connectors (having a cloud provider automatically deploy new instances to handle additional demand). Furthermore, if a single connector instance crashes, any applications that are in the process of sending packets to or from that ILP address (for example, using [STREAM](https://medium.com/interledger-blog/streaming-money-and-data-over-ilp-fabd76fc991e)) will need to re-establish their connection with a new ILP address.
+Current ILSPs that run multiple connectors configure different WebSocket URLs and ILP addresses for each instance. As a result, peering with another ILSP requires configuring each connector with _all_ of the URLs and ILP addresses of the peer’s connectors (n² connections). This complicates configuring connectors, exposes an ILSP’s internal network configuration to their peers (a potential security concern), and prevents “autoscaling” connectors (having a cloud provider automatically deploy new instances to handle additional demand). Furthermore, if a single connector instance crashes, any applications that are in the process of sending packets to or from that ILP address (for example, using [STREAM](https://medium.com/interledger-blog/streaming-money-and-data-over-ilp-fabd76fc991e)) will need to re-establish their connection with a new ILP address.
 
 ## Stateless, HTTP-Based Connectors
 

src/content/docs/get-started.md

@@ -36,19 +36,19 @@ Traditional payment networks operate independently from each other. Sending valu
 
 ## What is Interledger?
 
-Interledger is a network of computers that enables the sending of value across independent payment networks. Similar to how the internet routes packets information, Interledger routes packets of value. Computers on the Interledger network are called *nodes*. Nodes can take one or more of the following roles:
+Interledger is a network of computers that enables the sending of value across independent payment networks. Similar to how the internet routes packets information, Interledger routes packets of value. Computers on the Interledger network are called _nodes_. Nodes can take one or more of the following roles:
 
 - Sender – Initiates a value transfer.
 - Connector – Applies currency exchange and forwards packets of value. This is an intermediary node between the sender and the receiver.
 - Receiver – Receives the value.
 
 ![ILP nodes](/developers/img/ilp-nodes.svg)
 
-**Note:** The terms *Connector* and *Router* are used interchangeably throughout the documentation.
+**Note:** The terms _Connector_ and _Router_ are used interchangeably throughout the documentation.
 
 ## How does Interledger work?
 
-At the core of Interledger is the [Interledger Protocol (ILPv4)](https://interledger.org/developers/rfcs/interledger-protocol/), which is a set of rules that define how nodes should send value over the Interledger network. ILPv4 is a *request/response* protocol, where requests and responses are ILPv4 packets. Typically, a single aggregate payment from source to destination is split into multiple ILP packets. Each ILP packet contains transaction information, which is private to the nodes participating in the transaction. ILPv4 has three packet types - *Prepare*, *Fulfill*, and *Reject*.
+At the core of Interledger is the [Interledger Protocol (ILPv4)](https://interledger.org/developers/rfcs/interledger-protocol/), which is a set of rules that define how nodes should send value over the Interledger network. ILPv4 is a _request/response_ protocol, where requests and responses are ILPv4 packets. Typically, a single aggregate payment from source to destination is split into multiple ILP packets. Each ILP packet contains transaction information, which is private to the nodes participating in the transaction. ILPv4 has three packet types - _Prepare_, _Fulfill_, and _Reject_.
 
 ![ILP Packets](/developers/img/ilp-packets.svg)