Der frühere Paketkatalog dieser Website war nicht durch echte Zelyra-Pakete oder Downloadzahlen belegt. Einträge und Downloadzähler wurden entfernt. Verwende `zpm add` nicht: Dieser Befehl gehört nicht zum aktuellen CLI.
AKTUELLES RELEASE · EXPERIMENTELL · NICHT FÜR PRODUKTION
Projektvorlagen
Das veröffentlichte CLI kann Projekte mit den vorhandenen Vorlagen anlegen. Dabei entstehen Projektdateien – keine separat installierbaren Sprachpakete.
Projektlokale Importe
Der experimentelle 0.4-Zweig setzt ausgewählte Funktionen, Typen, Records, Tabellen, Seiten, MariaDB-gestützte Tableviews, benannte Views, Komponenten, Formulare, CRUD-Deklarationen, API-Routen und Authentifizierungskonfiguration aus lokalen Quelldateien zusammen. Importierte API-Handler und Typen werden im Quellmodul verknüpft; Authentifizierungstabellen werden gegen das gemeinsame Schema geprüft. Importierte Seitenrouten werden auf überlappende Muster geprüft. Datenbankbefehle bauen das gemeinsame Schema aus dem verknüpften Projekt auf. Unterstützt wird nur eine projektweite Datenbankverbindung. `context --format=json` zeigt deterministische Importkanten und derzeit öffentliche Funktionen, Typen, Records, Views und Komponenten je Datei. Modulübergreifende Page- und CRUD-Layout-Verweise sowie erkannte Komponenten-Tags in Page-, View-, Komponenten- und CRUD-Slot-HTML benötigen `pub` und einen direkten oder transitiven Importpfad (`E-MOD-007`, `E-MOD-020`). Die Komponentenerkennung scannt bekannte Tagnamen; sie ist kein vollständiger HTML-Parser und kein vollständiges Namespace-System. Das bleibt unveröffentlichte 0.4-Entwicklung; v0.3.0 enthält keine dieser Modulfunktionen.
`zelyra module plan <entry> <module-or-resource-id>` folgt expliziten Importen und statisch erkannten Verweisen aus dem Wirkungsgraphen. Enthalten sind bekannte Kanten von Seiten zu Views/Komponenten, SQL aus Seiten, Formularen und CRUD-Aktionen zu Tabellen, API-Handlern zu Funktionen, Typreferenzen aus API-Schemas und Funktionssignaturen sowie aus Records und Type Aliases, geschützten Ressourcen zur Authentifizierung, Authentifizierung zu Tabellen, Tabellenrelationen und Datenbankkonfiguration; nicht auflösbare Verweise werden gemeldet. Als Startpunkt sind eine Quelldatei oder eine unterstützte Seiten-/API-/CRUD-/Formular-/Tableview-Ressource möglich; die Ressourcenwahl enthält weiterhin alle Deklarationen ihres Quellmoduls. `declaration_closure` trennt über den bekannten statischen Wirkungsgraphen erreichbare Deklarationen von zusätzlichen Deklarationen in einbezogenen Quelldateien. Datenbankkonfigurationen werden separat unter `configuration_edges` ausgewiesen. Dieser Graph ist unvollständig. Der JSON-Plan führt Deklarationen je Datei unter `modules[].declarations` auf; diese Abhängigkeitsdaten sind kein eigenständiger Export. Dynamische oder nicht modellierte Abhängigkeiten, Assets, Laufzeitkonfiguration, externe Dienste und Docker-Artefakte bleiben außerhalb der Vorschau. `complete_deployment` ist ausdrücklich false: Das ist weder eine isolierte Ressourcenextraktion noch ein Docker-Exportmanifest oder eine eigenständig startbare Anwendung. Nichts davon ist in v0.3.0 enthalten.
Eigenständig betreibbare Anwendungsteile
Vorgesehen sind automatisch verdrahtete Modulabhängigkeiten und der Export ausgewählter Anwendungsteile als lauffähiges Docker-Deployment. Ein separat konfigurierbares Datenbankmodul und klare Schema-Verantwortung sind Ziele, keine verfügbaren Funktionen.
Paketmanager
Eine öffentliche Paket-Registry, Abhängigkeitsauflösung, Lockfiles und ein `zpm`-Installationsbefehl sind nicht implementiert. Auch ein Roadmap-Eintrag macht sie nicht verfügbar.