The former package catalogue on this site was not backed by real Zelyra packages or download data. Its entries and download counts have been removed. Do not use `zpm add`; that command is not part of the current CLI.
CURRENT RELEASE · EXPERIMENTAL · NOT FOR PRODUCTION
Project templates
The released CLI can create projects from its supported templates. These templates are generated project files, not separately installable language packages.
Project-local imports
The experimental 0.4 branch composes selected functions, types, records, tables, pages, MariaDB-backed tableviews, named views, components, forms, CRUD declarations, API routes, and authentication configuration from local source files. Imported API handlers and types are linked in their source module; authentication tables are checked against the shared schema. Imported page routes are checked for overlapping patterns. Database commands build the shared schema from the linked project. Only one project-wide database connection is supported. `context --format=json` reports deterministic import edges and currently public functions, types, records, views, and components per file. Cross-module page and CRUD layout references, plus recognized component tags in page, view, component, and CRUD-slot HTML, require `pub` declarations and a direct or transitive import path (`E-MOD-007`, `E-MOD-020`). Component discovery scans known tag names; it is not a full HTML parser or namespace system. This remains unreleased 0.4 development; v0.3.0 ships none of these module features.
`zelyra module plan <entry> <module-or-resource-id>` follows explicit imports and statically recognized references from the impact graph. It includes known page-to-view/component, page/form/CRUD SQL-to-table, API-handler-to-function, type references in API schemas, function signatures, records and type aliases, protected-resource-to-authentication, auth-to-table, table-relation, and database-configuration edges; unresolved references are reported. Start selection can be a source module or a supported page/API/CRUD/form/tableview resource ID; resource selection still includes every declaration in its owning source module. `declaration_closure` separates declarations reachable through the known static impact graph from additional declarations in included source files. Its database configuration dependencies are reported separately under `configuration_edges`. This graph is incomplete. The JSON plan lists declarations per file under `modules[].declarations`; dependency metadata is not a standalone export. Dynamic or unmodeled dependencies, assets, runtime configuration, external services, and Docker artifacts remain outside the preview. `complete_deployment` is explicitly false: this is not a resource-only extraction, Docker export manifest, or runnable standalone application. None of this is included in v0.3.0.
Independent application slices
The proposal is to wire module dependencies automatically and export a selected application slice as a runnable Docker deployment. A separately configurable database module and clear schema ownership are goals, not current features.
Package manager
A public package registry, dependency resolution, lockfiles, and a `zpm` install command are not implemented. The roadmap does not make them available by implication.