From 272cb54c81632eb7e5680fc366dbde801fb4f7dc Mon Sep 17 00:00:00 2001 From: derrickmehaffy Date: Mon, 12 Oct 2026 14:34:06 -0700 Subject: [PATCH 1/3] chore(deps): do not offer keyv majors until cache-manager supports them The production group bumped keyv to 6.1.0 on its own. Both providers pass their Keyv stores to cache-manager, which still depends on keyv ^5.6 in its latest release, and @keyv/redis 6 - already held back for its own reasons - is the release that peers on keyv 6. Alone, the bump broke every redis purge (#234). keyv has to move together with cache-manager and @keyv/redis, as one deliberate migration. Co-Authored-By: Claude Opus 5.5 --- .github/dependabot.yml | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/.github/dependabot.yml b/.github/dependabot.yml index 9ff205b3..1fe0d9ef 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -123,6 +123,17 @@ updates: - dependency-name: "@keyv/redis" update-types: ["version-update:semver-major"] + # keyv has to move with cache-manager and @keyv/redis, not ahead of them. + # Both providers hand their Keyv stores to cache-manager's createCache, + # and cache-manager 7.2.9 (the latest) still depends on keyv ^5.6, while + # @keyv/redis 6 peers on keyv ^6.1. Bumping keyv alone to 6.1.0 left the + # redis provider reading `cache.stores[0].opts.store`, which keyv 6 no + # longer populates, so every purge failed with "Cannot read properties of + # undefined (reading 'store')" (#234). Revisit with the @keyv/redis + # major above once cache-manager supports keyv 6. + - dependency-name: "keyv" + update-types: ["version-update:semver-major"] + # react-intl is governed by the admin runtime, not by us. The plugin peers # on ^6.0.0 and @strapi/admin bundles 6.6.2, so a major only produces an # unmergeable PR - the same situation as react and react-router-dom above. From 079d9f48575915a37e5c27e31bee1da5783d89ef Mon Sep 17 00:00:00 2001 From: derrickmehaffy Date: Mon, 12 Oct 2026 15:07:21 -0700 Subject: [PATCH 2/3] chore(deps): do not offer mermaid majors; explain the real keyv port cost mermaid 12 clips the second line of our flowchart labels and is outside vitepress-plugin-mermaid's declared peer range. No CI job renders the docs, so #231 was green while visibly breaking them. The keyv comment said keyv 6 "no longer populates" opts.store; it has no opts at all. More importantly it implied the port was an accessor fix. It is not: keyv 6 bridges @keyv/redis 3 and drops the default namespace, which would turn purges into silent no-ops, and the @keyv/redis that supports it moves to @redis/client while the redis plugin is being rewritten. Co-Authored-By: Claude Opus 5.5 --- .github/dependabot.yml | 33 +++++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/.github/dependabot.yml b/.github/dependabot.yml index 1fe0d9ef..6ed17bf0 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -123,14 +123,21 @@ updates: - dependency-name: "@keyv/redis" update-types: ["version-update:semver-major"] - # keyv has to move with cache-manager and @keyv/redis, not ahead of them. - # Both providers hand their Keyv stores to cache-manager's createCache, - # and cache-manager 7.2.9 (the latest) still depends on keyv ^5.6, while - # @keyv/redis 6 peers on keyv ^6.1. Bumping keyv alone to 6.1.0 left the - # redis provider reading `cache.stores[0].opts.store`, which keyv 6 no - # longer populates, so every purge failed with "Cannot read properties of - # undefined (reading 'store')" (#234). Revisit with the @keyv/redis - # major above once cache-manager supports keyv 6. + # keyv has to move with cache-manager, @keyv/redis and the redis plugin, + # not ahead of them. Both providers hand their Keyv stores to + # cache-manager's createCache, and cache-manager 7.2.9 (the latest) still + # depends on keyv ^5.6. Bumped alone to 6.1.0, keyv broke every redis + # purge (#234): it has no `opts` at all, so the provider's + # `cache.stores[0].opts.store` threw "Cannot read properties of undefined + # (reading 'store')". + # + # Fixing that accessor is not the port. keyv 6 wraps @keyv/redis 3 in a + # bridge adapter and no longer defaults the "keyv" namespace, so the + # SMEMBERS enumeration (#131) and cluster-safe delete (#100) would be + # skipped and purges would quietly match `undefined:*` instead of + # failing. The @keyv/redis that supports keyv 6 also swaps ioredis for + # @redis/client, and the redis plugin that supplies our client is being + # rewritten - do the three together, once cache-manager supports keyv 6. - dependency-name: "keyv" update-types: ["version-update:semver-major"] @@ -145,6 +152,16 @@ updates: - dependency-name: "jest-cli" update-types: ["version-update:semver-major"] + # mermaid 12 makes ELK and a new look the defaults, and renders our + # flowchart labels with their second line clipped ("GET on a cached + # route" becomes "GET on a cached"); `look: 'classic'` restores most of + # it but still clips. vitepress-plugin-mermaid also only declares + # support for mermaid 10 || 11. Nothing in CI renders the docs, so this + # can only be checked by eye in a browser. Revisit when the plugin + # supports 12. + - dependency-name: "mermaid" + update-types: ["version-update:semver-major"] + - package-ecosystem: github-actions directory: / schedule: From 3f47e2e28e4d70391966395ec813465851b5f443 Mon Sep 17 00:00:00 2001 From: derrickmehaffy Date: Mon, 12 Oct 2026 15:27:51 -0700 Subject: [PATCH 3/3] chore(deps): note that the node-redis move does not wait on keyv 6 @keyv/redis 4 and 5 already run on @redis/client and peer on keyv ^5, so the provider's move to node-redis (#239) can land without keyv 6. The previous comment implied the two had to move together. Co-Authored-By: Claude Opus 5.5 --- .github/dependabot.yml | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/.github/dependabot.yml b/.github/dependabot.yml index 6ed17bf0..2ce702bf 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -135,9 +135,12 @@ updates: # bridge adapter and no longer defaults the "keyv" namespace, so the # SMEMBERS enumeration (#131) and cluster-safe delete (#100) would be # skipped and purges would quietly match `undefined:*` instead of - # failing. The @keyv/redis that supports keyv 6 also swaps ioredis for - # @redis/client, and the redis plugin that supplies our client is being - # rewritten - do the three together, once cache-manager supports keyv 6. + # failing. Port it deliberately once cache-manager supports keyv 6. + # + # This does not hold up the move to node-redis: @keyv/redis 4 and 5 + # already use @redis/client and still peer on keyv ^5, so that migration + # (#239, with the plugin-redis v3 rewrite) can land on keyv 5. Only + # @keyv/redis 6 needs keyv 6. - dependency-name: "keyv" update-types: ["version-update:semver-major"]