chore(deps)(deps-dev): bump prettier and @types/prettier

.prettierrc.js

@@ -1,5 +1,8 @@
 module.exports = {
   ...require('@offchainlabs/prettier-config'),
+  // The shared config sets importOrder* options but doesn't declare the plugin that
+  // provides them; Prettier 3 no longer auto-loads plugins, so register it here.
+  plugins: ['@trivago/prettier-plugin-sort-imports'],
   // override here
   overrides: [
     {
@@ -8,6 +11,10 @@ module.exports = {
         parser: 'mdx',
         printWidth: 9999,
         proseWrap: 'preserve',
+        // Keep the import sorter out of fenced code blocks: doc examples mirror
+        // upstream tutorials, where import order and inline comments are
+        // deliberate. Embedded code is still formatted, just not reordered.
+        plugins: [],
       },
     },
   ],

docs/build-decentralized-apps/01-quickstart-solidity-remix.mdx

@@ -785,8 +785,13 @@ If you have any questions or feedback, reach out to us on [Discord](https://disc
 For a list of learning resources, repositories, and useful information about Solidity, see the [Solidity references](/arbitrum-essentials/reference/solidity-references.mdx) page.
 
 [^1]: The vending machine example was inspired by [Ethereum.org's "Introduction to Smart Contracts"](https://ethereum.org/en/developers/docs/smart-contracts/), which was inspired by [Nick Szabo's "From vending machines to smart contracts"](http://unenumerated.blogspot.com/2006/12/from-vending-machines-to-smart.html).
+
 [^2]: Although application front-ends are usually hosted by centralized services, smart contracts allow the underlying logic and data to be partially or fully decentralized. These smart contracts are hosted and executed by Ethereum's public, decentralized network of nodes. Arbitrum has its own network of nodes that use advanced cryptography techniques to "batch process" Ethereum transactions and then submit them to the Ethereum parent chain, which significantly reduces the cost of using Ethereum. All without requiring developers to compromise on security or decentralization.
+
 [^3]: There are multiple types of Ethereum nodes. The ones that earn **ETH** for processing and validating transactions are called _validators_. See [Nodes and Networks](https://docs.prylabs.network/docs/concepts/nodes-networks) for a beginner-friendly introduction to Ethereum's node types.
+
 [^4]: When our `VendingMachine` contract is deployed to Ethereum, it'll be hosted by Ethereum's decentralized network of nodes. Generally speaking, we won't be able to modify the contract's code after it's deployed.
+
 [^5]: To learn more about how Ethereum wallets work, see [Ethereum.org's introduction to Ethereum wallets](https://ethereum.org/en/wallets/).
+
 [^6]: Visit the [Gentle Introduction to Arbitrum](../get-started/arbitrum-introduction.mdx) for a beginner-friendly introduction to Arbitrum's Rollup protocol.

docs/launch-arbitrum-chain/chain-config/sequencer/timeboost.mdx

@@ -24,8 +24,8 @@ AEP fees will apply here in the future.
 
 - **Status:** Alpha—not formally supported yet for deployments on <a data-quicklook-from="arbitrum-chain">Arbitrum chains</a>
 - **Arbitrum Sepolia**: Feb 12, 2025
-- <a data-quicklook-from="arbitrum-one">**Arbitrum One**</a>: April 17, 2025{' '}
-- <a data-quicklook-from="arbitrum-nova">**Arbitrum Nova**</a>: April 17, 2025{' '}
+- <a data-quicklook-from="arbitrum-one">**Arbitrum One**</a>: April 17, 2025
+- <a data-quicklook-from="arbitrum-nova">**Arbitrum Nova**</a>: April 17, 2025
 
 ## tldr;
 

docs/partials/_troubleshooting-bridging-partial.mdx

@@ -14,7 +14,7 @@ In any case, the Bridge and your wallet will guide you through the process, show
 
 ### How long does it take before I receive my funds when I initiate a withdrawal from Arbitrum chains (One and Nova)?
 
-Using the official Arbitrum Bridge, the process will take *roughly* one week. However, some users opt to use third-party fast bridges, which often bypass this delay (remember that these bridges are created and maintained by third parties, so please DYOR!).
+Using the official Arbitrum Bridge, the process will take _roughly_ one week. However, some users opt to use third-party fast bridges, which often bypass this delay (remember that these bridges are created and maintained by third parties, so please DYOR!).
 
 There's some variability in the exact wall-clock time of the dispute window, plus there's some expected additional "padding" time on both ends (no more than about an hour, typically).
 

docs/partials/_troubleshooting-building-partial.mdx

@@ -49,7 +49,7 @@ The method you should (almost certainly) use is `Inbox.createRetryableTicket`.
 There are two differences between `createRetryableTicket` and `unsafeCreateRetryableTicket`:
 
 1. Method `createRetryableTicket` will check that provided L1 callvalue is sufficient to cover the costs of creating and executing the retryable ticket (at the specified parameters) and otherwise [revert directly at L1](https://docs.arbitrum.io/for-devs/troubleshooting-building#i-tried-to-create-a-retryable-ticket-but-the-transaction-reverted-on-l1--how-can-i-debug-the-issue). `unsafeCreateRetryableTicket`, in contrast, will allow a retryable ticket to be created that is guaranteed to revert on L2.
-2. Method `createRetryableTicket` will check if either the provided `excessFeeRefundAddress` or the `callValueRefundAddress` are contracts on L1; if they are, to prevent the situation where refunds are *guaranteed* to be irrecoverable on L2, it will convert them to their [address alias](https://developer.arbitrum.io/arbos/l1-to-l2-messaging#address-aliasing), providing a *potential* path for fund recovery. `unsafeCreateRetryableTicket` will allow the creation of a retryable ticket with refund addresses that are L1 contracts; since no L1 contract can alias to an address that is also itself an L1 contract, refunds to these addresses on L2 will be irrecoverable.
+2. Method `createRetryableTicket` will check if either the provided `excessFeeRefundAddress` or the `callValueRefundAddress` are contracts on L1; if they are, to prevent the situation where refunds are _guaranteed_ to be irrecoverable on L2, it will convert them to their [address alias](https://developer.arbitrum.io/arbos/l1-to-l2-messaging#address-aliasing), providing a _potential_ path for fund recovery. `unsafeCreateRetryableTicket` will allow the creation of a retryable ticket with refund addresses that are L1 contracts; since no L1 contract can alias to an address that is also itself an L1 contract, refunds to these addresses on L2 will be irrecoverable.
    (Astute observers may note a third ticket creation method, `createRetryableTicketNoRefundAliasRewrite`; this is included only for backwards compatibility, but should be considered deprecated in favor of `unsafeCreateRetryableTicket`)
 
 ### Why do I get "custom tx type" errors when I use hardhat?

docs/partials/_troubleshooting-users-partial.mdx

@@ -24,7 +24,7 @@ Arbitrum Rollup is an Optimistic Rollup protocol; it is trustless and permission
 
 By contrast, Arbitrum AnyTrust introduces a trust assumption in exchange for lower fees; data availability is managed by a Data Availability Committee (DAC), a fixed, permissioned set of entities. We introduce some threshold, `K`, with the assumption that at least `K` members of the committee are honest. For simplicity, we'll hereby assume a committee of size 20 and a `K` value of 2:
 
-If 19 out of the 20 committee members *and* the Sequencer are malicious and colluding together, they can break the chain's safety (and, e.g., steal users' funds); this is the new trust assumption.
+If 19 out of the 20 committee members _and_ the Sequencer are malicious and colluding together, they can break the chain's safety (and, e.g., steal users' funds); this is the new trust assumption.
 
 If anywhere between 2 and 18 of the committee members are well behaved, the AnyTrust chain operates in "Rollup mode"; i.e., data gets posted on L1.
 
@@ -48,23 +48,23 @@ Nope; once an Arbitrum transaction is included on L1, there is no way it can be
 
 ### ...okay but if there's a dispute, will my transaction get delayed?
 
-The only thing that a dispute can add delay to is the confirmation of L2-to-L1 messages. All other transactions continue to be processed, even while a dispute is still ongoing. (Additionally, in practice, most L2-to-L1 messages represent withdrawals of fungible assets; these can be trustlessly completed *even during a dispute* via trustless fast "liquidity exit" applications. See [L2-to-L1 Messages](https://developer.arbitrum.io/arbos/l2-to-l1-messaging)).
+The only thing that a dispute can add delay to is the confirmation of L2-to-L1 messages. All other transactions continue to be processed, even while a dispute is still ongoing. (Additionally, in practice, most L2-to-L1 messages represent withdrawals of fungible assets; these can be trustlessly completed _even during a dispute_ via trustless fast "liquidity exit" applications. See [L2-to-L1 Messages](https://developer.arbitrum.io/arbos/l2-to-l1-messaging)).
 
 ### Are "Sequencers" the same entities as "Validators"? Can a centralized Sequencer act maliciously (e.g., steal all my money)?
 
 No and no!
 
 An Arbitrum Chain's Sequencer(s) and Validators and completely distinct entities, with their own distinct roles.
 
-The [Sequencer](https://developer.arbitrum.io/sequencer) is the entity granted specific privileges over ordering transactions; once the Sequencer commits to an ordering (by posting a batch on Ethereum), it has no say over what happens next (i.e., execution). A malicious/faulty Sequencer can do things like reordering transactions or *temporarily* delaying a transaction's inclusion — things which could be, to be sure, annoying and bad — but can do nothing to compromise the chain's safety.
+The [Sequencer](https://developer.arbitrum.io/sequencer) is the entity granted specific privileges over ordering transactions; once the Sequencer commits to an ordering (by posting a batch on Ethereum), it has no say over what happens next (i.e., execution). A malicious/faulty Sequencer can do things like reordering transactions or _temporarily_ delaying a transaction's inclusion — things which could be, to be sure, annoying and bad — but can do nothing to compromise the chain's safety.
 
-The *Validators* are the ones responsible for the safety of the chain; i.e., making bonded claims about the chain state, disputing each other, etc.
+The _Validators_ are the ones responsible for the safety of the chain; i.e., making bonded claims about the chain state, disputing each other, etc.
 
-Currently, on Arbitrum One, the Sequencer is a centralized entity maintained by Offchain Labs. Eventually, we expect the single Sequencer to be replaced by a distributed committee of Sequencers who come to consensus on transaction ordering. This upgrade will be an improvement; we don't want you to have to trust us not to reorder your transactions. However, it also isn't *strictly* necessary for Arbitrum One to achieve its most fundamental properties.
+Currently, on Arbitrum One, the Sequencer is a centralized entity maintained by Offchain Labs. Eventually, we expect the single Sequencer to be replaced by a distributed committee of Sequencers who come to consensus on transaction ordering. This upgrade will be an improvement; we don't want you to have to trust us not to reorder your transactions. However, it also isn't _strictly_ necessary for Arbitrum One to achieve its most fundamental properties.
 
 In other words: **_An Arbitrum Rollup chain with a centralized Sequencer could theoretically still be trustless!_**
 
-Which is to say — the more important thing than decentralizing the Sequencer, i.e., the thing you ought to care more about — is decentralizing the *Validators*.
+Which is to say — the more important thing than decentralizing the Sequencer, i.e., the thing you ought to care more about — is decentralizing the _Validators_.
 
 Arbitrum One's validator set is currently allowlisted; over time, we expect [governance](https://docs.arbitrum.foundation/) to expand the allowlist and eventually be removed entirely.
 

docusaurus.config.js

@@ -1,13 +1,15 @@
+import rehypeKatex from 'rehype-katex';
+import remarkMath from 'remark-math';
+
+import { inkeepBaseSettings, inkeepExampleQuestions, inkeepModalSettings } from './inkeep.js';
+import { redirects } from './redirects.config.js';
+
 // @ts-nocheck
 // Note: type annotations allow type checking and IDEs autocompletion
 require('dotenv').config();
 
 const markdownPreprocessor = require('./scripts/markdown-preprocessor');
 const { themes: prismThemes } = require('prism-react-renderer');
-import remarkMath from 'remark-math';
-import rehypeKatex from 'rehype-katex';
-import { inkeepBaseSettings, inkeepModalSettings, inkeepExampleQuestions } from './inkeep.js';
-import { redirects } from './redirects.config.js';
 
 // Routes that exist in the Docusaurus build but aren't standalone, indexable pages.
 // Shared between the sitemap and llms.txt so both indexes stay in sync.

package.json

@@ -95,10 +95,11 @@
     "@offchainlabs/notion-docs-generator": "0.1.2",
     "@offchainlabs/prettier-config": "0.3.0",
     "@signalwire/docusaurus-plugin-llms-txt": "^1.2.2",
+    "@trivago/prettier-plugin-sort-imports": "^5.2.2",
     "@tsconfig/docusaurus": "^2.0.9",
     "@types/d3": "^7.4.3",
     "@types/node": "^22.20.1",
-    "@types/prettier": "2.7.3",
+    "@types/prettier": "3.0.0",
     "@types/react": "^19.2.17",
     "@types/react-dom": "^19.2.0",
     "@types/semver": "^7.7.1",
@@ -110,7 +111,7 @@
     "husky": "^9.1.7",
     "markdown-link-extractor": "^4.0.3",
     "markdownlint-cli": "^0.49.1",
-    "prettier": "^2.8.3",
+    "prettier": "^3.9.6",
     "remark-mdx": "^3.1.1",
     "remark-parse": "^11.0.0",
     "semver": "^7.8.5",

scripts/lib/generated-partial.ts

@@ -4,7 +4,6 @@
  * deterministic Prettier-formatted output, a `--check` mode for CI, and uniform
  * success/failure handling.
  */
-
 import fs from 'fs';
 import path from 'path';
 import prettier from 'prettier';
@@ -36,8 +35,8 @@ export async function writeOrCheck(
   { check }: { check: boolean },
 ): Promise<void> {
   const config = await prettier.resolveConfig(filePath);
-  // prettier v2's format() is synchronous; resolveConfig() is not.
-  const formatted = prettier.format(content, { ...config, filepath: filePath });
+  // Both resolveConfig() and, as of prettier v3, format() are async.
+  const formatted = await prettier.format(content, { ...config, filepath: filePath });
 
   if (check) {
     const current = fs.existsSync(filePath) ? fs.readFileSync(filePath, 'utf-8') : '';

src/components/AddressExplorerLink.tsx

@@ -1,5 +1,5 @@
-import React from 'react';
 import { getAddress, isAddress } from '@ethersproject/address';
+import React from 'react';
 
 type ChainID = 1 | 42161 | 42170 | 8453 | 11155111 | 421614 | 84532;
 

src/components/Cards/Card.js

@@ -1,5 +1,6 @@
-import React from 'react';
 import Link from '@docusaurus/Link';
+import React from 'react';
+
 import styles from './Card.module.css';
 
 function Card({ title, description, to, href, target }) {

src/components/CustomDetails/index.tsx

@@ -1,5 +1,6 @@
-import React from 'react';
 import Details from '@theme/Details';
+import React from 'react';
+
 import styles from './styles.module.css';
 
 interface Props {

src/components/FAQStructuredData/index.js

@@ -4,9 +4,8 @@
  * @typedef { import('./types').FAQStructuredData } FAQStructuredData - Schema.org structured data format for FAQs
  * @typedef { import('./types').FAQ } FAQ - Individual FAQ item with question, answer and key
  */
-
-import React from 'react';
 import { useLocation } from '@docusaurus/router';
+import React from 'react';
 
 /**
  * A component that generates and renders Schema.org FAQ structured data for SEO

src/components/FloatingHoverModal/index.js

@@ -1,19 +1,20 @@
-import React, { useState, cloneElement } from 'react';
 import {
-  useFloating,
-  useHover,
-  useFocus,
-  useDismiss,
-  useRole,
-  useInteractions,
   FloatingPortal,
-  offset,
+  autoUpdate,
   flip,
+  offset,
   shift,
-  autoUpdate,
+  useDismiss,
+  useFloating,
+  useFocus,
+  useHover,
+  useInteractions,
   useMergeRefs,
+  useRole,
 } from '@floating-ui/react';
 import { MDXProvider } from '@mdx-js/react';
+import React, { cloneElement, useState } from 'react';
+
 // Remove Link import - we'll use a span instead to avoid Docusaurus broken link detection (Docusaurus's build will fail if a <Link> points to a non-existent page)
 import './styles.css';
 

src/components/GenerateTroubleshootingReportWidget.js

@@ -1,5 +1,5 @@
-import React from 'react';
 import BrowserOnly from '@docusaurus/BrowserOnly';
+import React from 'react';
 
 export const GenerateTroubleshootingReportWidget = () => {
   let appendConfigDetailsToOutput = function (output) {

src/components/HeaderBadges/index.tsx

@@ -1,5 +1,5 @@
-import React from 'react';
 import BrowserOnly from '@docusaurus/BrowserOnly';
+import React from 'react';
 
 export const HeaderBadges = () => {
   return (

src/components/ImageZoom/index.tsx

@@ -3,8 +3,7 @@
  *
  * A React component that adds a click-to-zoom feature to images with smooth animations.
  */
-
-import React, { useState, useEffect } from 'react';
+import React, { useEffect, useState } from 'react';
 import { createPortal } from 'react-dom';
 
 interface ImageZoomProps {

src/components/InteractiveDiagrams/Bold/EdgeChallengeFlow/ControlBar.tsx

@@ -1,4 +1,5 @@
 import React from 'react';
+
 import { SPEED_OPTIONS } from './constants';
 
 interface ControlBarProps {

src/components/InteractiveDiagrams/Bold/EdgeChallengeFlow/D3EdgeTree.tsx

@@ -1,6 +1,7 @@
-import React, { useRef, useEffect, useCallback } from 'react';
-import type { LevelGroup, AppliedState, LevelMeta, TreeNode } from './types';
-import { buildTreeData, resolveLevelType, formatRangeText, shortHex } from './edgeChallengeLogic';
+import React, { useCallback, useEffect, useRef } from 'react';
+
+import { buildTreeData, formatRangeText, resolveLevelType, shortHex } from './edgeChallengeLogic';
+import type { AppliedState, LevelGroup, LevelMeta, TreeNode } from './types';
 
 interface D3EdgeTreeProps {
   group: LevelGroup;

src/components/InteractiveDiagrams/Bold/EdgeChallengeFlow/EdgeChallengeFlow.tsx

@@ -1,15 +1,16 @@
-import React, { useState, useEffect } from 'react';
 import BrowserOnly from '@docusaurus/BrowserOnly';
 // @ts-ignore – module alias resolved by Docusaurus at build time
 import useBaseUrl from '@docusaurus/useBaseUrl';
-import type { EdgeChallengeData } from './types';
-import { useEdgeChallengeState } from './useEdgeChallengeState';
+import React, { useEffect, useState } from 'react';
+
 import ControlBar from './ControlBar';
+import D3EdgeTree from './D3EdgeTree';
+import EventTimeline from './EventTimeline';
 import FlowSteps from './FlowSteps';
 import NodeDetailsPanel from './NodeDetailsPanel';
-import EventTimeline from './EventTimeline';
-import D3EdgeTree from './D3EdgeTree';
 import { ARBISCAN_BASE_URL } from './constants';
+import type { EdgeChallengeData } from './types';
+import { useEdgeChallengeState } from './useEdgeChallengeState';
 
 function EdgeChallengeFlowInner() {
   const [data, setData] = useState<EdgeChallengeData | null>(null);

src/components/InteractiveDiagrams/Bold/EdgeChallengeFlow/EventTimeline.tsx

@@ -1,6 +1,7 @@
 import React, { useEffect, useRef } from 'react';
-import type { DecodedEvent, LevelMeta, EdgeAddedMeta } from './types';
+
 import { formatEvent } from './edgeChallengeLogic';
+import type { DecodedEvent, EdgeAddedMeta, LevelMeta } from './types';
 
 interface EventTimelineProps {
   appliedEvents: DecodedEvent[];

src/components/InteractiveDiagrams/Bold/EdgeChallengeFlow/FlowSteps.tsx

@@ -1,4 +1,5 @@
 import React from 'react';
+
 import { FLOW_STEPS } from './constants';
 
 interface FlowStepsProps {

src/components/InteractiveDiagrams/Bold/EdgeChallengeFlow/NodeDetailsPanel.tsx

@@ -1,7 +1,8 @@
 import React, { useCallback } from 'react';
-import type { RangeNode, AppliedState, LevelMeta, EdgeAddedMeta } from './types';
-import { shortHex, normalizeHex, formatRangeText, resolveLevelType } from './edgeChallengeLogic';
+
 import { ARBISCAN_BASE_URL } from './constants';
+import { formatRangeText, normalizeHex, resolveLevelType, shortHex } from './edgeChallengeLogic';
+import type { AppliedState, EdgeAddedMeta, LevelMeta, RangeNode } from './types';
 
 interface NodeDetailsPanelProps {
   selectedNodeKey: string | null;