Migrated from yarn v1 to pnpm

- Replaced yarn v1 with pnpm workspaces and pnpm-lock.yaml
- Updated all package.json scripts from yarn to pnpm
- Converted workspace deps to workspace:* protocol
- Added pnpm.overrides (replaces yarn resolutions)
- Updated CI workflows for pnpm with caching
- Updated monobundle for pnpm deploy packaging
- Added pnpm-workspace.yaml, .npmrc
- Removed yarn.lock and .yarnrc files

Author: 9larsons

.agents/skills/add-admin-api-endpoint/SKILL.md

@@ -11,7 +11,7 @@ description: Add a new endpoint or endpoints to Ghost's Admin API at `ghost/api/
 2. The endpoint file should create a controller object using the JSDoc type from (@tryghost/api-framework).Controller, including at minimum a `docName` and a single endpoint definition, i.e. `browse`. 
 3. Add routes for each endpoint to `ghost/core/core/server/web/api/endpoints/admin/routes.js`.
 4. Add basic `e2e-api` tests for the endpoint in `ghost/core/test/e2e-api/admin` to ensure the new endpoints function as expected.
-5. Run the tests and iterate until they pass: `cd ghost/core && yarn test:single test/e2e-api/admin/{test-file-name}`.
+5. Run the tests and iterate until they pass: `cd ghost/core && pnpm test:single test/e2e-api/admin/{test-file-name}`.
 
 ## Reference
 For a detailed reference on Ghost's API framework and how to create API controllers, see [reference.md](reference.md).

.agents/skills/add-private-feature-flag/SKILL.md

@@ -17,8 +17,8 @@ Adds a new private feature flag to Ghost. Private flags appear in Labs settings
    - Add a new entry to the `features` array with `title`, `description`, and `flag` (must match the string in `labs.js`).
 
 3. **Run tests and update the config API snapshot**
-   - Unit: `cd ghost/core && yarn test:single test/unit/shared/labs.test.js`
-   - Update snapshot and run e2e: `cd ghost/core && UPDATE_SNAPSHOTS=1 yarn test:single test/e2e-api/admin/config.test.js`
+   - Unit: `cd ghost/core && pnpm test:single test/unit/shared/labs.test.js`
+   - Update snapshot and run e2e: `cd ghost/core && UPDATE_SNAPSHOTS=1 pnpm test:single test/e2e-api/admin/config.test.js`
    - Review the diff of `ghost/core/test/e2e-api/admin/__snapshots__/config.test.js.snap` to confirm only your new flag was added.
 
 ## Notes

.agents/skills/create-database-migration/SKILL.md

@@ -7,15 +7,15 @@ description: Create a database migration to add a table, add columns to an exist
 
 ## Instructions
 
-1. Create a new, empty migration file: `cd ghost/core && yarn migrate:create <kebab-case-slug>`. IMPORTANT: do not create the migration file manually; always use this script to create the initial empty migration file. The slug must be kebab-case (e.g. `add-column-to-posts`).
+1. Create a new, empty migration file: `cd ghost/core && pnpm migrate:create <kebab-case-slug>`. IMPORTANT: do not create the migration file manually; always use this script to create the initial empty migration file. The slug must be kebab-case (e.g. `add-column-to-posts`).
 2. The above command will create a new directory in `ghost/core/core/server/data/migrations/versions` if needed, create the empty migration file with the appropriate name, and bump the core and admin package versions to RC if this is the first migration after a release.
 3. Update the migration file with the changes you want to make in the database, following the existing patterns in the codebase. Where appropriate, prefer to use the utility functions in `ghost/core/core/server/data/migrations/utils/*`.
 4. Update the schema definition file in `ghost/core/core/server/data/schema/schema.js`, and make sure it aligns with the latest changes from the migration.
-5. Test the migration manually: `yarn knex-migrator migrate --v {version directory} --force`
+5. Test the migration manually: `pnpm knex-migrator migrate --v {version directory} --force`
 6. If adding or dropping a table, update `ghost/core/core/server/data/exporter/table-lists.js` as appropriate.
 7. If adding or dropping a table, also add or remove the table name from the expected tables list in `ghost/core/test/integration/exporter/exporter.test.js`. This test has a hardcoded alphabetically-sorted array of all database tables — it runs in CI integration tests (not unit tests) and will fail if the new table is missing.
-8. Run the schema integrity test, and update the hash: `yarn test:single test/unit/server/data/schema/integrity.test.js`
-9. Run unit tests in Ghost core, and iterate until they pass: `cd ghost/core && yarn test:unit`
+8. Run the schema integrity test, and update the hash: `pnpm test:single test/unit/server/data/schema/integrity.test.js`
+9. Run unit tests in Ghost core, and iterate until they pass: `cd ghost/core && pnpm test:unit`
 
 ## Examples
 See [examples.md](examples.md) for example migrations.

.codex/environments/environment.toml

@@ -4,7 +4,5 @@ name = "Ghost"
 
 [setup]
 script = '''
-yarn setup
-(cd node_modules/sqlite3 && npm run install)
-(cd ghost/parse-email-address && yarn build)
+pnpm setup
 '''

.cursor/rules/pnpm.mdc

@@ -0,0 +1,7 @@
+---
+description:
+globs:
+alwaysApply: true
+---
+This repository uses pnpm as a package manager.
+All commands are prefixed with `pnpm` instead of `npm` or `yarn`.

.cursor/rules/yarn.mdc

@@ -1,6 +1,6 @@
 {
   "setup-worktree": [
     "git submodule update --init --recursive",
-    "yarn"
+    "pnpm"
   ]
 }

.cursor/worktrees.json

@@ -62,7 +62,7 @@ There is no need to include what modules have changed in the commit message, as
 
 ### Submitting Pull Requests
 
-We aim to merge any straightforward, well-understood bug fixes or improvements immediately, as long as they pass our tests (run `yarn test` to check locally). We generally don’t merge new features and larger changes without prior discussion with the core product team for tech/design specification.
+We aim to merge any straightforward, well-understood bug fixes or improvements immediately, as long as they pass our tests (run `pnpm test` to check locally). We generally don’t merge new features and larger changes without prior discussion with the core product team for tech/design specification.
 
 Please provide plenty of context and reasoning around your changes, to help us merge quickly. Closing an already open issue is our preferred workflow. If your PR gets out of date, we may ask you to rebase as you are more familiar with your changes than we will be.
 

.github/CONTRIBUTING.md

@@ -38,6 +38,13 @@ runs:
         echo "::warning::Dependency cache could not be restored after retry - installing dependencies from scratch"
         bash .github/scripts/install-deps.sh
 
+    - name: Re-link dependencies after cache restore
+      if: steps.dep-cache.outputs.cache-hit == 'true' || steps.dep-cache-retry-attempt.outputs.cache-hit == 'true'
+      shell: bash
+      run: |
+        echo "::notice::Re-linking pnpm dependencies after cache restore"
+        bash .github/scripts/install-deps.sh --force
+
     - name: Set cache miss output
       id: check-cache
       shell: bash

.github/actions/restore-cache/action.yml

@@ -3,7 +3,7 @@
 
 [ -n "$CI" ] && exit 0
 
-yarn lint-staged --relative
+pnpm lint-staged --relative
 lintStatus=$?
 
 if [ $lintStatus -ne 0 ]; then