Skip to main content

Requirements and upgrades

Supported package ranges, effective runtime requirements, installation commands, and an upgrade verification path.

This reference describes @lupinum/ginko-docs 0.3.0-rc.1. Install the layer together with its Ginko Content peer in the consuming Nuxt application.

Ginko Content 0.4 provides the Comark 0.6 contract, canonical Shiki integration, and the render-policy behavior required by this release. Earlier Content versions are not supported.

terminal
pnpm add -D @lupinum/ginko-docs@0.3.0-rc.1 @lupinum/ginko-content@0.4.0-rc.1

Declared peer ranges

The published Ginko Docs package declares these exact peer dependencies:

PackageRange
@lupinum/ginko-content>=0.4.0-rc.1 <0.5.0
nuxt>=4.4.7 <5
vue^3.5.35
vue-router^5.1.0

The current compatible Ginko Content line adds these requirements:

RequirementRange or rule
Node.js^22.18.0 || ^24.11.0 || >=26.0.0
Nuxt through Ginko Content>=4.4.7 <5
Vue through Ginko Content^3.5.35
Module formatESM; CommonJS require() is not supported

Ginko Docs and Ginko Content declare the same Nuxt range: >=4.4.7 <5. Use a supported Node release from the Ginko Content engine range.

Check installed versions

Inspect the consumer's resolved dependency graph before debugging behavior:

terminal
pnpm why @lupinum/ginko-docs
pnpm why @lupinum/ginko-content
pnpm why nuxt
pnpm why vue
pnpm why vue-router
node --version

Resolve peer warnings instead of relying on a package manager to select an untested combination. A single installed copy of Ginko Content, Vue, and Vue Router avoids split runtime state.

Upgrade the supported set together

Update the layer and its direct peers in one change:

terminal
pnpm up @lupinum/ginko-docs @lupinum/ginko-content nuxt vue vue-router
pnpm exec nuxi prepare
pnpm exec nuxi typecheck
pnpm build

For a static site, also generate and serve the actual public output:

terminal
pnpm generate
pnpm dlx serve .output/public

Review these contracts after an upgrade:

  • content.config.ts still uses defineGinkoDocsConfig() from the public content entry.
  • The selected locale mode still matches the content directory layout.
  • Required docs, blog, and author fields pass strict validation.
  • Custom MDC tags still merge the built-in map and declare a narrow portable policy.
  • App-config overrides still correspond to live fields in the current type.
  • Static output contains HTML, search assets, sitemap, robots, raw Markdown, and both LLM catalogs.
  • Nitro deployments still negotiate Markdown and expose MCP only where those runtime features are intended.

Do not copy the layer's complete default app config into the consumer during an upgrade. Keep a small override so new safe defaults can merge normally and the application owns only its identity and deliberate feature choices.