@pulse-compute/wasm-compiler

Support tier: Implementation/transitive surface Audience: Pulse compiler and release maintainers. Install directly: No for application projects; use the pulse CLI. Supported entry points: None for application authors. Stability: Internal compiler interface; no application-author compatibility guarantee. npm: @pulse-compute/wasm-compiler Canonical replacement: @pulse-compute/cli Canonical documentation: Package guide

This release-status block is generated from the synchronized Pulse 1.0.0-beta.10 package policy.

Whole-project compiler implementation used by the pulse workflow. Application projects should use @pulse-compute/cli, not import this package directly.

Responsibilities

• resolve and validate compiler inputs;
• compile canonical handler source into values, effects, continuations, and capability metadata;
• compile explicitly declared JSON schemas through the schema package;
• discover trusted package-owned manifests and invoke their owning builders;
• merge package effects with canonical operations;
• emit versioned canonical plans and build artifacts;
• expose implementation diagnostics to the product workflow.

Boundaries

The compiler orchestrates contracts but does not own:

• product command parsing or project UX;
• provider execution;
• provider SDK behavior;
• package-specific AST rules for GRIP or assets;
• schema payload semantics;
• application runtime authority.

Package-specific lowering belongs to the package owning the facade. Provider realization belongs to provider packages. Shared protocol vocabulary belongs to @pulse-compute/wasm-contracts.

Provider packages are not production dependencies of this compiler. Direct compiler consumers supply the selected provider in their project context; the product CLI owns its bundled Node/Fastly dependencies. Provider-neutral imports, compilation and legacy executable help do not load providers. Legacy proof commands load only their selected provider when invoked. Repository proof scripts retain provider development dependencies.

The canonical API, Native-plan and Native-compiler facades use declared package imports and surface missing or unexported dependencies without checkout-relative recovery. Other historical loaders are outside this migration.

Internal compiler spine

The compiler connects root extraction, surface recognition, normalization, classification, validation, canonical IR, native lowering, provider realization, and artifact verification through a fixed package-internal pipeline. The pipeline is not exported and is not a plugin framework. Compiler refactors must preserve checked-in metadata, diagnostics, native-plan, and generated-Wasm evidence unless an explicit contract migration authorizes a difference.

The canonical-source and Router frontends now share package-internal handler-surface recognition and compatibility diagnostic authorities. The shared surface authority consumes the contracts package vocabulary, retains frontend-specific syntax compatibility, records facts without changing compiler outputs, and does not enable async or widen source support by itself. Canonical IR generation remains behind legacy compatibility envelopes until the dedicated frontend migration phases.

Exported implementation modules

The package exports its root implementation plus focused compiler, CLI, extractor, config resolver, diagnostics, build-manifest, canonical API compiler, and canonical project compiler modules. These are synchronized internal interfaces without an application-author compatibility guarantee.

Validation

Compiler changes should be covered by focused static/lowering tests, canonical project inspection, provider-plan parity, packed-package discovery where relevant, and the release documentation gates.

See the installed implementation package guide and compilation concepts.