YAZA native CLI and macOS installer

Current status

compiler/native_cli.yz is a YAZA-written, self-hosted compiler/CLI slice. It supports --version, --help, new, generate, db migrate, db status, audit --security, check, test, bench, build, and run. The security audit emits YAZA JSON or SARIF 2.1.0 for limited source/configuration heuristics; it does not audit third-party dependencies or provide taint analysis or fuzzing. From a project folder, yaza run uses src/main.yz (or main.yz); yaza generate creates Postman and OpenAPI files for an API project. The new command renders API, web, fullstack, and mobile starters. The API starter has controller, service, repository, model, interface, route, and test structure; the native API compiler checks service/repository interface signatures and runs the included Product Catalog server.

The native compiler emits C and invokes Apple's Clang to build YAZA programs. The installed CLI is an arm64 Mach-O binary and does not bundle or invoke Python. The bootstrap script requires an existing native seed (dist/yaza or YAZA_BOOTSTRAP), rebuilds the compiler through native stages, and checks that stages two and three emit identical C.

The HTTP implementation uses a readiness-driven event loop plus a bounded worker pool for generated controller routes and PostgreSQL-backed readiness probes. It keeps at most the configured capacity, from 1 to 127 sockets (default 64), reads partial requests without blocking other connections, and closes an incomplete request after five seconds; the API smoke test verifies a stalled header does not block /healthz. Completed controller requests run on worker threads with copied request state; the event loop alone owns sockets and response writes. PostgreSQL operations remain blocking calls inside workers and use bounded timeouts. The server serves static JSON and sample CRUD inferred from API controller metadata. Explicit GET and POST controller actions can execute imported YAZA function chains and read metadata-validated Text path/query/header values, typed primitive path/query values, scalar JSON fields, and nested request shapes with optional scalar/nested fields through Option[T] accessors. Omitted and JSON null optional fields become none; unknown, missing-required, malformed, and wrong-typed fields are rejected before dispatch. With DATABASE_URL, it uses the YAZA-owned PostgreSQL protocol, a bounded connection pool, parameterized PostgreSQL JSONB operations, and transactional row-locked updates; yaza db migrate applies ordered migrations and verifies SHA-256 checksums. Without a database URL it uses volatile in-memory records. Requests have bounded header/body sizes, strict framing, Host validation, JSON content-type enforcement, safe percent-decoding for path/query components, a shared Bearer token or explicitly configured route-scoped JWT requirement for non-loopback IPv4 binds, exact-origin CORS, health/readiness endpoints, Prometheus HTTP and worker-pool metrics, and structured JSON access logs that omit query strings. Bearer tokens are compared in constant time for equal-length values and duplicate Authorization headers fail closed. PostgreSQL connections use connect, statement, lock, and idle-transaction timeouts. Startup output shows the bind address, event-loop mode, connection/deadline caps, routes, auth/CORS state, storage mode, and shutdown signal. Variant/map request fields, token issuance, centralized role/ownership authorization, HTTPS, and composable middleware are not implemented. A matched JWT handler can read bounded verified string claims with http_auth_claim_text(name) -> Option[Text]; public and shared-Bearer routes cannot obtain claims from headers. Route-scoped JWT HS256 verification is available with explicit configuration. The included Compose credential is a local development placeholder and must not be used for a deployed service.

Native builds support YAZA_BUILD_MODE=debug or YAZA_BUILD_MODE=release. Use yaza build --sanitize <file.yz> -o <binary> or set YAZA_SANITIZE=1 to compile with AddressSanitizer and UndefinedBehaviorSanitizer. scripts/fuzz-runtime.sh builds a libFuzzer harness for the HTTP request and JSON object parsers on Clang distributions with libFuzzer support; if the runtime is unavailable, it runs a deterministic ASan/UBSan mutation fallback. yaza test invokes each test program in a subprocess and continues through compile errors; tests/test-runner-resilience.sh checks this behavior. The runtime stdin_read() returns up to 1 MiB of text and rejects NUL bytes; file_append(path, text) appends text. tests/cli-io-smoke.sh exercises both. The process_timeout(command, arguments, milliseconds) built-in returns the child's exit code or 124 on timeout; it sends SIGTERM, then SIGKILL after a short grace period, to the child process group. Output is inherited rather than captured. Native compiler errors include file and line locations for the main source compilation path, but multiple errors are not accumulated yet.

The macOS package targets Apple Silicon arm64. Linux and Windows require separate target support and installers. Native builds can use YAZA_ARGON2_ROOT to select a provider prefix containing include/argon2.h and lib/libargon2.a; the compiler also checks the packaged provider path and common Homebrew paths. scripts/build-macos-pkg.sh stages the static Argon2 provider, version metadata, and license so installed users can build programs using std/crypto/password.yz without installing Homebrew. A custom package-build provider prefix also needs lib/pkgconfig/libargon2.pc so the staged version is accurate. The package build succeeded and pkgutil --payload-files confirmed the provider archive, header, and license in the payload; a program compiled and ran using the extracted bundled provider. It has not been installed on a clean Mac. The .pkg is unsigned; this managed build host adds AppleDouble provenance records to its payload, so this output is provisional until rebuilt and install-tested on a clean Mac.

Build the self-hosted CLI

Install Apple's Command Line Tools for clang and ensure jq is on PATH for SARIF smoke validation, then run from the project root:

scripts/bootstrap-macos-cli.sh

The script requires an existing native YAZA compiler as its seed. Native stages build the later compilers, and the last two generated C files are compared for the self-host check. Only the final YAZA-compiled executable is copied to dist/yaza; no Python interpreter or virtual environment is packaged. The script strips managed provenance attributes and adds an ad-hoc local signature so the binary runs on this Mac; this is not a Developer ID signature and does not establish publisher identity.

Try the CLI:

dist/yaza --version
dist/yaza new --api catalog-api
dist/yaza check catalog-api/src/main.yz
cd catalog-api
../dist/yaza generate
../dist/yaza run

To generate a Postman collection from the route and controller declarations:

../dist/yaza generate

The collection is written under catalog-api/docs/api/. You can import that JSON file into Postman and send the root or GET /api/products request to the running local server.

Run yaza generate from an API project to write the Postman collection, openapi.json, and swagger.json under docs/api/. yaza generate --openapi and yaza generate --swagger write only the requested specification there. Both include route operations, declared parameter types, and request examples.

For a local smoke check, the catalog server also exposes GET /healthz, GET /readyz, and GET /metrics. Set DATABASE_URL and apply migrations to persist this sample resource; otherwise data is held in memory. The event loop can receive multiple active connections, but synchronous route/SQL execution can still delay other work and this prototype is not a production concurrency runtime.

yaza test finds .test.yz and _test.yz files under tests/ and runs each as a native program. Test programs can use Boolean assert statements. API projects also include sh tests/http-smoke.sh for HTTP integration checks using curl; with DATABASE_URL, this checks that data survives a server restart. yaza bench <source.yz> <iterations> compiles one non-API program once, then measures repeated native process runs; it is not an HTTP throughput benchmark.

For native builds, the compiler searches for runtime/yaza_runtime.c.inc in the current project and nearby source-tree locations, then under YAZA_STDLIB_DIR/runtime, then under YAZA_RUNTIME_DIR, and finally under /usr/local/share/yaza/runtime or /opt/homebrew/share/yaza/runtime. Set YAZA_STDLIB_DIR to the YAZA distribution root when using a source checkout from outside that checkout; this root also supplies imports such as std/pg/uri. YAZA_RUNTIME_DIR may point directly to the directory containing yaza_runtime.c.inc. The macOS package places the runtime source, std/ modules, and templates under /usr/local/share/yaza. The runtime support is compiled into programs as needed; it is not a separate interpreter.

Build the macOS installer

After building dist/yaza, run:

scripts/build-macos-pkg.sh

The package places the executable at /usr/local/bin/yaza, runtime support at /usr/local/share/yaza/runtime/yaza_runtime.c.inc, and templates at /usr/local/share/yaza/templates.

dist/YAZA-Native-CLI-0.1.0-macos-arm64.pkg

The package script does not install it. On a clean Apple Silicon Mac, install and verify with:

sudo installer -pkg dist/YAZA-Native-CLI-0.1.0-macos-arm64.pkg -target /
yaza --version
yaza new --api catalog-api

The package is unsigned and has not been system-installed on the managed build host. Inspect package contents with:

pkgutil --payload-files dist/YAZA-Native-CLI-0.1.0-macos-arm64.pkg

Next compiler work

The updated language blueprint recommends a Rust production compiler and makes YAZA self-hosting optional after the language stabilizes. Treat this native compiler as an early CLI/compiler slice, not as proof of production-language completeness. Next work is to decide the production compiler path, then implement the type system, diagnostics, safety model, runtime, and executable layered API handlers. Extend the test runner with HTTP/database integration support. Sign and install-test the Mac package on a clean machine; build independent Linux and Windows packages according to the chosen target order.

← Kembali ke semua dokumentasiVersi dan status rilis →