[pull] main from TryGhost:main#1204
Merged
Merged
Conversation
no ref We do not need to block our own releases for security reasons.
no ref ghost/core pinned `zod` inline at 4.1.12, which is exactly the catalog value. With `catalogMode: strict`, every other zod consumer already references the catalog; pointing ghost/core at `catalog:` keeps the version single-sourced.
…ugin split (#28319) no ref Two ESLint plugins were drifting: - `eslint-plugin-react-hooks` was 5.2.0 in admin but 4.6.2 in 7 other React apps by accident. Unified everyone on 5.2.0 via the catalog. No new lint errors surface; the few `exhaustive-deps` warnings already exist on `main` under 4.6.2. - `eslint-plugin-tailwindcss` tracks the Tailwind v4/v3 lane split, so it's moved into the catalog (4.0.0-beta.0) and the `tailwind3` named catalog (3.18.2) to mirror `tailwindcss` itself — making the split intentional rather than incidental.
…8318) no ref `@testing-library/jest-dom` was split between 6.9.1 (5 apps) and 5.17.0 (admin-x-framework, comments-ui, sodo-search), with nothing holding them together. Adds it to the catalog at 6.9.1 and points every consumer at `catalog:`, bumping the three laggards and preventing future drift. sodo-search's test setup used the v5 `import matchers … expect.extend(matchers)` pattern that v6 removed, so it's switched to the `@testing-library/jest-dom/vitest` import already used by posts/admin-x-settings.
IndexNow (behind the `indexnow` labs flag) pings `api.indexnow.org` when a post is published or edited, resolving the post URL via `urlService.facade.getUrlForResource(...)`. That returns a `/404/` URL when a published post is not owned by any route — e.g. an imported or members post that falls outside the site's collections, or a routing config with no catch-all. In that case the ping submitted `https://<site>/404/` instead of a post URL.
no ref The React 18 (admin) vs React 17 (public bundles) split was inlined across ~14 `package.json` files with nothing enforcing which lane held which version. ESLint and Tailwind already express their version splits through named catalogs (`eslint9`, `tailwind3`); React was the one core split that didn't. This adds `react`, `react-dom`, and `@testing-library/react` to the catalog plus a `react17` named catalog, and points every consumer at the right entry. The eventual React bump then becomes a single catalog decision instead of another chance to drift. This is a no-op for resolved versions — the lockfile diff only reshapes specifiers into catalog refs; no package resolution changes. `^18.2.0` peer ranges are intentionally left loose.
no ref Moves cross-workspace dependencies that already agree on a single version into the pnpm catalog, so future bumps are one decision and Renovate can group them (see PLA-58). All consumers resolve to the same version today, so this is a no-op — the lockfile only gains catalog entries and reshapes specifiers; no package resolution changes. **Catalogued:** - Four multi-workspace singles: `@ebay/nice-modal-react`, `react-hot-toast`, `mingo`, `tsx` - The shared `@radix-ui/*` set (`avatar`, `checkbox`, `form`, `popover`, `separator`, `switch`, `tabs`, `tooltip`) — a lockstep cluster worth centralising even at two consumers, since the pieces move together. **Deliberately left inline:** single-consumer `@radix-ui/*` packages and other deps used in only one workspace — cataloguing a dep with one consumer adds indirection with no drift-prevention benefit. The bar applied here is "shared across workspaces, or a lockstep cluster," not raw consumer count.
Without grouping rules, each catalogued dependency still opens its own Renovate PR — so a single named-catalog bump can fan out into several PRs, which is the churn the catalog was meant to collapse. This adds the missing half of the catalog strategy: one reviewable PR per named catalog. Renovate tags every pnpm catalog dependency with a `pnpm.catalog.<name>` depType, so the rules match on depType rather than restating each catalog's package list. They stay correct as entries are added to or removed from `pnpm-workspace.yaml`: - `react17 catalog` — `react`, `react-dom`, `@testing-library/react` - `eslint9 catalog` — `eslint`, `@eslint/js` - `tailwind3 catalog` — `tailwindcss`, `eslint-plugin-tailwindcss` These also override the shared preset's `group:monorepos` behaviour. That preset groups e.g. `eslint` + `@eslint/js` and `react` + `react-dom` *by name* across the whole repo, which would otherwise merge the default-catalog version lane (eslint 8, React 18) and the named-catalog lane (eslint 9, React 17) into a single PR. Matching by depType keeps each lane in its own PR — the separation the named catalogs exist to enforce. The main `catalog:` is intentionally left ungrouped. Its entries are independent of one another, so grouping them would only couple unrelated bumps and let one risky update block the rest of the group from merging. Per-catalog grouping is applied only where the catalog represents a genuine lockstep version lane. Composes with the existing rules: the named-catalog deps don't overlap the vulnerability-alert carve-out, the Ember/CSS freeze rules, or the `@tryghost/*` groups, so current behaviour is unchanged. The off-hours schedule is untouched. The `react17` group only takes effect once the React catalog split lands. ref https://linear.app/ghost/issue/PLA-58
ref https://linear.app/ghost/issue/PLA-59 `@faker-js/faker` was declared at two versions across the workspace — `8.4.1` in `e2e` and `9.9.0` in `apps/stats`. This catalogues a single `9.9.0` entry and points both consumers at it, collapsing the split so a future bump is one decision.
ref https://linear.app/ghost/issue/PLA-61 `ghost/core` was the last maintained workspace on `@faker-js/faker` 7.x. This points it at the catalogued `9.9.0` (e2e and stats converged in #28327) and migrates the seeder call sites off the APIs faker removed in v8/v9. faker is reachable only through the demo/dev data generator (`reset:data`) — there are no faker call sites in `test/`, and nothing asserts on generated output, so resolved values shifting between majors is cosmetic.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )