Anforderungen und Upgrades

Unterstützte Paketbereiche, effektive Laufzeitanforderungen, Installationsbefehle und ein Prüfpfad für Upgrades.

Diese Referenz beschreibt @lupinum/ginko-docs 0.3.0-rc.1. Installiere den Layer zusammen mit seinem Ginko-Content-Peer in der konsumierenden Nuxt-Anwendung.

Ginko Content 0.4 stellt den Comark-0.6-Vertrag, die kanonische Shiki-Integration und das für dieses Release erforderliche Render-Policy-Verhalten bereit. Frühere Content-Versionen werden nicht unterstützt.

Terminal

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

Deklarierte Peer-Bereiche

Das veröffentlichte Ginko-Docs-Paket deklariert diese exakten Peer-Abhängigkeiten:

Paket	Bereich
`@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`

Die aktuelle kompatible Ginko-Content-Linie ergänzt folgende Anforderungen:

Anforderung	Bereich oder Regel
Node.js	`^22.18.0 \|\| ^24.11.0 \|\| >=26.0.0`
Nuxt durch Ginko Content	`>=4.4.7 <5`
Vue durch Ginko Content	`^3.5.35`
Modulformat	ESM; CommonJS `require()` wird nicht unterstützt

Ginko Docs und Ginko Content deklarieren denselben Nuxt-Bereich: >=4.4.7 <5. Verwende eine unterstützte Node-Version aus dem Engine-Bereich von Ginko Content.

Installierte Versionen prüfen

Kontrolliere vor der Fehlersuche den aufgelösten Abhängigkeitsgraphen des Consumers:

Terminal

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

Löse Peer-Warnungen, statt dem Paketmanager eine ungetestete Kombination zu überlassen. Jeweils eine installierte Kopie von Ginko Content, Vue und Vue Router verhindert geteilten Laufzeitzustand.

Unterstützten Satz gemeinsam aktualisieren

Aktualisiere Layer und direkte Peers in einer Änderung:

Terminal

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

Generiere und serviere bei einer statischen Website zusätzlich die tatsächliche öffentliche Ausgabe:

Terminal

pnpm generate
pnpm dlx serve .output/public

Prüfe nach einem Upgrade diese Verträge:

content.config.ts verwendet weiterhin defineGinkoDocsConfig() aus dem öffentlichen Content-Einstieg.
Der gewählte Sprachmodus passt weiterhin zur Content-Verzeichnisstruktur.
Pflichtfelder von Docs, Blog und Autoren bestehen die strikte Validierung.
Eigene MDC-Tags führen die eingebaute Map zusammen und deklarieren eine schmale portable Policy.
App-Config-Overrides entsprechen weiterhin aktiven Feldern des aktuellen Typs.
Statische Ausgabe enthält HTML, Such-Assets, Sitemap, Robots, Raw-Markdown und beide LLM-Kataloge.
Nitro-Deployments handeln Markdown weiterhin nur dort aus und stellen MCP nur dort bereit, wo diese Laufzeitfunktionen vorgesehen sind.

Kopiere bei einem Upgrade nicht die vollständige Standard-App-Config in den Consumer. Ein kleines Override lässt neue sichere Standards normal zusammenführen und überlässt der Anwendung nur ihre Identität und bewussten Funktionsentscheidungen.