Skip to content

PR 5/N (2.0 stack): align Vue ecosystem deps with SDK 17, add extension compatibility tables - #27

Merged
elisiondan merged 1 commit into
nextfrom
pr/05-vue-ecosystem
May 12, 2026
Merged

PR 5/N (2.0 stack): align Vue ecosystem deps with SDK 17, add extension compatibility tables#27
elisiondan merged 1 commit into
nextfrom
pr/05-vue-ecosystem

Conversation

@elisiondan

Copy link
Copy Markdown
Member

Summary

The Directus SDK 17 (landed in PR 4) already pulls in modern Vue, Pinia, and @vueuse/core transitively. The module's declared devDeps were just stale against what's actually installed and bundled. This PR aligns the declarations so reading package.json matches reality.

  • Vue: ^3.4.27^3.5.0 (installed 3.5.24).
  • Pinia: ^2.1.4^2.3.1 (installed 2.3.1).
  • @vueuse/core: ^10.2.1^14.0.0 (installed 14.0.0).

Why Pinia stays on 2.x

Pinia is externalized at extension build time — the runtime instance is provided by Directus' admin app. Directus 11 ships Pinia 2.3.1 via the SDK 17 dep tree. Declaring Pinia 3 in the extension would build fine but introduces a build-time/runtime type drift for no real-world benefit; the SFC code paths used in this module are compatible with both majors. Cleanest answer: match the runtime version that Directus actually provides.

Extension READMEs — compatibility tables

Both extensions/module/README.md and extensions/sync-hook/README.md get a small 🧭 Compatibility section above the install instructions:

Extension version Directus Notes
2.x ^11.0.0 Current.
1.x ^10.10.0 Frozen. Pin with npm install <package>@^1 if you can't upgrade Directus yet.

This is the user-visible signal that 2.0 drops Directus 10 support and that stragglers have a pin to fall back on (the same line we'll repeat in MIGRATION.md in PR 6).

Verified

  • npm run build — minified production bundles for both extensions.
  • npm run test — 49/49.
  • npm run lint — 0 errors (10 pre-existing warnings).
  • npm run format — clean.

Test plan

  • CI passes.
  • Run npm run dev and confirm the admin module still renders identically — no Vue 3.4→3.5 regressions in the SFCs, no @vueuse/core API surface regressions (the only composables used are stock useDebounceFn, useStorage etc., all stable across 10→14).
  • Bundle size hasn't ballooned (module went 386 KB → still ~386 KB after this PR).

Out of scope

  • MIGRATION.md + final 2.0.0 version bump — PR 6.
  • Aggregate check script + husky — PR 7.
  • Fixing the deferred Pinia store typecheck errors from SDK 17 — Stage 2.

🤖 Generated with Claude Code

… tables.

The Directus SDK 17 transitive deps already pull in Vue 3.5.x, Pinia 2.3.x, and @vueuse/core 14.x. The module's declared devDeps were just stale against what's actually being bundled. This PR aligns the declarations so they match reality.

- extensions/module: vue ^3.4.27 -> ^3.5.0, @vueuse/core ^10.2.1 -> ^14.0.0, pinia ^2.1.4 -> ^2.3.1.

Pinia stays on 2.x intentionally. The Directus admin app externalizes Pinia at extension build time; the runtime instance comes from Directus, which ships pinia@2.3.1 via the SDK 17 dependency tree. Declaring pinia@^3 in the extension would risk a build-time/runtime type drift even though the SFC code would still work in practice.

READMEs:
- extensions/module/README.md and extensions/sync-hook/README.md gain a Compatibility table showing 2.x supports Directus ^11.0.0 and 1.x is frozen at ^10.10.0 with the pin instruction (npm install ...@^1) for users who can't move to Directus 11 yet.

Verified: build (minified production), 49/49 tests, lint clean (10 pre-existing warnings), format clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@elisiondan
elisiondan merged commit 67a7a3a into next May 12, 2026
1 check passed
@elisiondan
elisiondan deleted the pr/05-vue-ecosystem branch May 12, 2026 08:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant