Revert inappropriate yarn->pnpm changes in develop-docs files that document other repositories

Author: cursoragent

develop-docs/backend/api/public.mdx

@@ -378,7 +378,7 @@ e.g. `/Users/yourname/code/sentry/tests/apidocs/openapi-derefed.json`.
 
 In `sentry-docs`:
 
-1. Run `OPENAPI_LOCAL_PATH=<COPIED_FULL_PATH> DISABLE_THUMBNAILS=1 pnpm dev` and substitute
+1. Run `OPENAPI_LOCAL_PATH=<COPIED_FULL_PATH> DISABLE_THUMBNAILS=1 yarn dev` and substitute
    `<COPIED_FULL_PATH>` with the path to your local openapi-derefed.json.
 
    Unfortunately changes do not automatically reflect in your local server, so you will need to

develop-docs/development-infrastructure/environment/index.mdx

@@ -65,12 +65,12 @@ First we will use [mkcert](https://github.com/FiloSottile/mkcert) to create and
 brew install mkcert
 brew install nss # if you use Firefox
 brew install caddy
-pnpm mkcert-localhost
+yarn mkcert-localhost
 ```
 
 Then we will run the reverse proxy as needed:
 ```shell
-pnpm https-proxy
+yarn https-proxy
 ```
 
 After the server is running we can visit the dev server using `https` at port `:8003` instead of over `http` at `:8000`.

develop-docs/frontend/upgrade-policies.mdx

@@ -33,7 +33,7 @@ On the other hand, choosing to constantly keep packages updated to the absolute
 
 - Upgrading can in some cases be a non-trivial effort for marginal gains. Validating even small upgrades takes time, often when really nothing has changed. (This is of course a slippery slope, wait too long and packages can become exponentially more work to upgrade)
 
-- There is a cost to too much `package.json` churn such as developers having to constantly run `pnpm install` on every git pull.
+- There is a cost to too much `package.json` churn such as developers having to constantly run `yarn install` on every git pull.
 
 - A security vulnerability may be introduced in a new version that was not previously present. If we had waited to upgrade until the patch we would not be vulnerable.
 
@@ -52,13 +52,13 @@ You may not have to do this manually! See the below section on [Take advantage o
 ### Seeing what can be upgraded
 
 ```bash
-pnpm outdated --color | sort
+yarn outdated --color | sort
 ```
 
 ### Upgrading packages
 
 ```bash
-pnpm upgrade --latest [package-name] [...]
+yarn upgrade --latest [package-name] [...]
 ```
 
 <Alert>
@@ -70,7 +70,7 @@ Don't forget to upgrade the `@types/[package-name]` package as well if necessary
 If you would like to upgrade a group of packages (for example `@babel`) you can use
 
 ```bash
-pnpm upgrade --latest $(pnpm outdated | cut -d' ' -f1 | grep [group-name])
+yarn upgrade --latest $(yarn outdated | cut -d' ' -f1 | grep [group-name])
 ```
 
 ## Proper testing of upgrades
@@ -149,21 +149,21 @@ For example, some dependencies such as `webpack` fall both into the app build **
 
    - Does `sentry devserver` still correctly run the client-side application?
 
-   - Does `pnpm dev-ui` still run the client-only version of the application?
+   - Does `yarn dev-ui` still run the client-only version of the application?
 
    Depending on what package you're upgrading, you'll what to consider what to test. For example, if you upgraded `fork-ts-checker-webpack-plugin` you'll want to validate that types are still being checked in development.
 
 5. **Upgrade the package in getsentry if applicable**
 
    Developer tooling and build packages are currently duplicated in `getsentry`'s `package.json`. For those packages, it is important to remember that you will need to upgrade the package in both places.
 
-6. **Read the `pnpm-lock.yaml` diff**
+6. **Read the `yarn.lock` diff**
 
    It's good to understand exactly what has changed with the upgrade. It's generally a bad thing if upgrading has caused a discrepancy in shared sub dependency versions. For example, if you upgrade `lodash` but another top level package specifies that it needs and older version of `lodash` we will now have **two versions** of `lodash` installed. That means two separate versions of `lodash` will be shipped!
 
-   Generally you will want to make sure nothing has duplicated versions, in that case you may need to use `[pnpm-dedupe](https://www.npmjs.com/package/pnpm-dedupe)` or in the worst case you may need to upgrade the package which is pulling in the offending older versions.
+   Generally you will want to make sure nothing has duplicated versions, in that case you may need to use `[yarn-deduplicate](https://www.npmjs.com/package/yarn-deduplicate)` or in the worst case you may need to upgrade the package which is pulling in the offending older versions.
 
-   See [The Ultimate Guide to pnpm lockfiles](https://pnpm.io/pnpm-lock.html) for an in-depth look on how these work.
+   See [The Ultimate Guide to yarn.lock Lockfiles](https://www.arahansen.com/the-ultimate-guide-to-yarn-lock-lockfiles/) for an in-depth look on how these work.
 
 7. **Validate in production after the upgrade is merged**
 

develop-docs/services/chartcuterie.mdx

@@ -108,7 +108,7 @@ chart-rendering.enabled: true
 Currently you need to manually build the configuration module in your development environment.
 
 ```shell
-pnpm build-chartcuterie-config
+yarn build-chartcuterie-config
 ```
 
 You can then boot the Chartcuterie devservice. If the devservice doesn't start
@@ -141,7 +141,7 @@ Chartcuterie.
 
 ### Updating chart types locally
 
-Currently you need to rebuild the configuration module using `pnpm
+Currently you need to rebuild the configuration module using `yarn
 build-chartcuterie-config` on every change. This may be improved in the future.
 
 ## How it works