NOQERI / NQON + PACKAGES
Packages for the whole pack.
Projects use Noqeri code in .noqeri files, portable NQON for configuration and a content-addressed lockfile. A registry client and release selection logic exist, but installing packages does not make native host ABI dependencies disappear.
← THE FULL FIELD GUIDE01 / Project files and NQON
project.nqon is a data manifest, not executable code. Runtime/nqon.mjs and Tools/nqon.mjs parse portable NQON independently of the compiler. It supports bare/quoted strings, objects, arrays, finite numbers, booleans, null and comments; duplicate keys are invalid.
name = demo
version = "0.1.0"
entry = "src/main.noqeri"
packages {
toolkit = "1.2.0"
}NQON SPECIFICATION ↗02 / Start and validate a project
The Stage-0 CLI exposes new, manifest, lock and audit. Run each in the actual repository/project context rather than assuming an npm-compatible package.json workflow.
noqeri new demo
noqeri manifest demo/project.nqon
noqeri lock demo/project.nqon
noqeri audit demo03 / Resolver and registry boundaries
Runtime/package-manager.mjs implements namespace/name@semver coordinates, checksum verification, offline cache and bounded package traversal. Registry releases live outside the compiler repo and are not guaranteed to exist for every dependency name.
REGISTRY CLIENT IMPLEMENTATION ↗OFFICIAL PACKAGE REGISTRY ↗04 / Standard library versus packages
Lib/std contains checked source modules for numeric, collections, JSON, HTTP, cryptography, concurrency, graphics and more. Several capabilities are host/extern interfaces requiring a linked provider; a source module's existence does not guarantee every environment executes it.
STANDARD LIBRARY SOURCE ↗PROJECT AND WORKSPACE CONTRACT ↗05 / The lockfile matters
A lockfile pins dependency/version/integrity selections. Validate provenance before using code, especially packages with native bindings, separately licensed artifacts or unqualified registry endpoints.
DISTRIBUTION GUIDE ↗