Uses new PackageManager component in local-development/wrangler.mdx

Author: korinne

src/content/docs/workers/local-development/index.mdx

@@ -11,8 +11,8 @@ Cloudflare Workers provides two primary ways to develop and test your code local
 
 You can test changes locally using the following:
 
-- **Wrangler’s built-in dev command** [`wrangler dev`](/workers/wrangler/commands/#dev), which uses [`workerd`](https://github.com/cloudflare/workerd) and Miniflare to simulate production behavior and resource bindings locally. Wrangler also offers the option to develop against remote resources with `wrangler dev --remote`, allowing you to test directly with data stored on Cloudflare's network.
+- **Wrangler’s built-in dev command** [`wrangler dev`](/workers/wrangler/commands/#dev), which uses [`workerd`](https://github.com/cloudflare/workerd) and Miniflare to simulate production behavior and resource bindings locally. Wrangler also offers the option to [develop against remote resources](/workers/local-development/wrangler/#develop-using-remote-resources-and-bindings) with `wrangler dev --remote`, allowing you to test directly with data stored on Cloudflare's network.
 
-- The **Cloudflare Vite plugin** (`@cloudflare/vite-plugin`), which integrates directly with Vite and runs your code in the same `workerd` runtime, while also offering features like [hot module replacement (HMR)](https://vite.dev/guide/features.html#hot-module-replacement). The Vite plugin is currently considered in **beta**.
+- The **Cloudflare Vite plugin** (`@cloudflare/vite-plugin`), which integrates directly with [Vite](https://vite.dev/) and runs your code in the [Worker Runtime](/workers/reference/how-workers-works/) ([`workerd`](https://github.com/cloudflare/workerd)), while also offering features like [hot module replacement (HMR)](https://vite.dev/guide/features.html#hot-module-replacement). The Vite plugin is currently in open beta.
 
 Both approaches aim to provide confidence that your local environment will closely match the production runtime, removing the need to [test against remote resources](#develop-using-remote-resources-and-bindings).

src/content/docs/workers/local-development/wrangler.mdx

@@ -7,6 +7,8 @@ head: []
 description: Locally develop and test changes with `wrangler dev`
 ---
 
+import { PackageManagers } from "~/components";
+
 ## Start a local development server
 
 :::note
@@ -19,9 +21,7 @@ Users new to Wrangler CLI and Cloudflare Workers should visit the [Wrangler Inst
 
 Wrangler provides a [`dev`](/workers/wrangler/commands/#dev) command that starts a local server for developing your Worker. Make sure you have `npm` installed and run the following in the folder containing your Worker application:
 
-```sh
-npx wrangler dev
-```
+<PackageManagers type="exec" pkg="wrangler" args="dev" />
 
 `wrangler dev` will run the Worker directly on your local machine. `wrangler dev` uses a combination of `workerd` and [Miniflare](https://github.com/cloudflare/workers-sdk/tree/main/packages/miniflare), a simulator that allows you to test your Worker against additional resources like KV, Durable Objects, WebSockets, and more.
 
@@ -65,9 +65,11 @@ When you run `wrangler dev` Wrangler stores local resources in a `.wrangler/stat
 
 If you prefer to specify a directory, you can use the [`--persist-to`](/workers/wrangler/commands/#dev) flag with `wrangler dev` like this:
 
-```sh
-npx wrangler dev --persist-to <DIRECTORY>
-```
+<PackageManagers
+	type="exec"
+	pkg="wrangler"
+	args="dev --persist-to <DIRECTORY>"
+/>
 
 Using this will write all local storage and cache to the specified directory instead of `.wrangler`.
 
@@ -90,9 +92,11 @@ The following [Wrangler commands](/workers/wrangler/commands/) have a `--local`
 
 If using `--persist-to` to specify a custom folder with `wrangler dev` you should also add `--persist-to` with the same directory name along with the `--local` flag when running the commands above. For example, to put a custom KV key into a local namespace via the CLI you would run:
 
-```sh
-npx wrangler kv key put test 12345 --binding MY_KV_NAMESPACE --local --persist-to worker-local
-```
+<PackageManagers
+	type="exec"
+	pkg="wrangler"
+	args="kv key put test 12345 --binding MY_KV_NAMESPACE --local --persist-to worker-local"
+/>
 
 Running `wrangler kv key put` will create a new key `test` with a value of `12345` on the local namespace specified via the binding `MY_KV_NAMESPACE` in the [Wrangler configuration file](/workers/wrangler/configuration/). This example command sets the local persistence directory to `worker-local` using `--persist-to`, to ensure that the data is created in the correct location. If `--persist-to` was not set, it would create the data in the `.wrangler` folder.
 
@@ -115,9 +119,7 @@ API_ACCOUNT_ID = "local_example_user"
 
 There may be times you want to develop against remote resources and bindings. To run `wrangler dev` in remote mode, add the `--remote` flag, which will run both your code and resources remotely:
 
-```sh
-npx wrangler dev --remote
-```
+<PackageManagers type="exec" pkg="wrangler" args="dev --remote" />
 
 For some products like KV and R2, remote resources used for `wrangler dev --remote` must be specified with preview ID/names in the [Wrangler configuration file](/workers/wrangler/configuration/) such as `preview_id` for KV or `preview_bucket name` for R2. Resources used for remote mode (preview) can be different from resources used for production to prevent changing production data during development. To use production data in `wrangler dev --remote`, set the preview ID/name of the resource to the ID/name of your production resource.