chore(deps): update dependency prettier to v3.6.0 (vitejs#20273)

renovate[bot] · web-flow · commit 0c3c6732893a · 2025-06-23T03:18:03.000Z
Co-authored-by: renovate[bot] &lt;29139614+renovate[bot]@users.noreply.github.com&gt;
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -232,18 +232,15 @@ For a mock dependency, make sure you add a `@vitejs/test-` prefix to the package
 - Checkout a topic branch from a base branch (e.g. `main`), and merge back against that branch.
 
 - If adding a new feature:
-
   - Add accompanying test case.
   - Provide a convincing reason to add this feature. Ideally, you should open a suggestion issue first, and have it approved before working on it.
 
 - If fixing a bug:
-
   - If you are resolving a special issue, add `(fix #xxxx[,#xxxx])` (#xxxx is the issue id) in your PR title for a better release log (e.g. `fix: update entities encoding/decoding (fix #3899)`).
   - Provide a detailed description of the bug in the PR. Live demo preferred.
   - Add appropriate test coverage if applicable.
 
 - If it's a chore:
-
   - For typos and comment changes, try to combine multiple of them into a single PR.
   - **Note that we discourage contributors from submitting code refactors that are largely stylistic.** Code refactors are only accepted if it improves performance, or objectively improves code quality (e.g. makes a related bug fix or feature implementation easier, and it is as a separate PR to improve git history).
     - The reason is that code readability is subjective. The maintainers of this project have chosen to write the code in its current style based on our preferences, and we do not want to spend time explaining our stylistic preferences. Contributors should just respect the established conventions when contributing code. Another aspect of it is that large scale stylistic changes result in massive diffs that touch multiple files, adding noise to the git history and makes tracing behavior changes across commits more cumbersome.
diff --git a/docs/guide/api-plugin.md b/docs/guide/api-plugin.md
@@ -338,7 +338,6 @@ Vite plugins can also provide hooks that serve Vite-specific purposes. These hoo
   Dedicated hook for transforming HTML entry point files such as `index.html`. The hook receives the current HTML string and a transform context. The context exposes the [`ViteDevServer`](./api-javascript#vitedevserver) instance during dev, and exposes the Rollup output bundle during build.
 
   The hook can be async and can return one of the following:
-
   - Transformed HTML string
   - An array of tag descriptor objects (`{ tag, attrs, children }`) to inject to the existing HTML. Each tag can also specify where it should be injected to (default is prepending to `<head>`)
   - An object containing both as `{ html, tags }`
@@ -417,13 +416,11 @@ Vite plugins can also provide hooks that serve Vite-specific purposes. These hoo
     server: ViteDevServer
   }
   ```
-
   - `modules` is an array of modules that are affected by the changed file. It's an array because a single file may map to multiple served modules (e.g. Vue SFCs).
 
   - `read` is an async read function that returns the content of the file. This is provided because on some systems, the file change callback may fire too fast before the editor finishes updating the file and direct `fs.readFile` will return empty content. The read function passed in normalizes this behavior.
 
   The hook can choose to:
-
   - Filter and narrow down the affected module list so that the HMR is more accurate.
 
   - Return an empty array and perform a full reload:
diff --git a/docs/guide/backend-integration.md b/docs/guide/backend-integration.md
@@ -45,7 +45,6 @@ If you need a custom integration, you can follow the steps in this guide to conf
    ```
 
    In order to properly serve assets, you have two options:
-
    - Make sure the server is configured to proxy static assets requests to the Vite server
    - Set [`server.origin`](/config/server-options.md#server-origin) so that generated asset URLs will be resolved using the back-end server URL instead of a relative path
 
@@ -100,7 +99,6 @@ If you need a custom integration, you can follow the steps in this guide to conf
      }
    }
    ```
-
    - The manifest has a `Record<name, chunk>` structure
    - For entry or dynamic entry chunks, the key is the relative src path from project root.
    - For non entry chunks, the key is the base name of the generated file prefixed with `_`.
@@ -131,7 +129,6 @@ If you need a custom integration, you can follow the steps in this guide to conf
 
    Specifically, a backend generating HTML should include the following tags given a manifest
    file and an entry point:
-
    - A `<link rel="stylesheet">` tag for each file in the entry point chunk's `css` list
    - Recursively follow all chunks in the entry point's `imports` list and include a
      `<link rel="stylesheet">` tag for each CSS file of each imported chunk.
diff --git a/docs/guide/static-deploy.md b/docs/guide/static-deploy.md
@@ -265,7 +265,6 @@ You can deploy your Vite app as a Static Site on [Render](https://render.com/).
 3. Connect your GitHub/GitLab account or use a public repository.
 
 4. Specify a project name and branch.
-
    - **Build Command**: `npm install && npm run build`
    - **Publish Directory**: `dist`
 
diff --git a/package.json b/package.json
@@ -65,7 +65,7 @@
     "lint-staged": "^16.1.2",
     "picocolors": "^1.1.1",
     "playwright-chromium": "^1.53.1",
-    "prettier": "3.5.3",
+    "prettier": "3.6.0",
     "rollup": "^4.40.0",
     "simple-git-hooks": "^2.13.0",
     "tsx": "^4.20.3",
diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
