npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@page-engine/page-runtime-core

v0.4.0

Published

Pure Runtime Manifest to Execution Plan compiler for PageEngine.

Readme

@page-engine/page-runtime-core

Pure compiler from Runtime Manifest to Execution Plan for the PageEngine declarative front-end engine.

Takes a validated page.runtime-manifest/v1 and produces the page.execution-plan/v1 the browser runtime consumes: the recursive render tree, widget mount order, interaction wiring, data binding schedules, and effect projections. The compiler is pure — it performs no I/O and no time-dependent computation, so identical manifests yield identical plans.

  • Pure: no DOM, network, filesystem, clock, or random source access.
  • Startup-time fail-closed validation of the manifest against the same contracts enforced at build time.
  • Depends only on @page-engine/page-contracts.

Install

npm install @page-engine/page-runtime-core

Requires Node >= 22.12. ESM only.

Minimal example

import { compilePageExecutionPlan, verifyRuntimeManifest } from "@page-engine/page-runtime-core";

const verification = verifyRuntimeManifest({ manifest });
if (!verification.ok) throw new Error(JSON.stringify(verification.diagnostics));

const result = compilePageExecutionPlan({ manifest, rendererRegistry, contractRegistry });
if (!result.ok) throw new Error(JSON.stringify(result.diagnostics));
console.log(result.plan);

Reusing a verified registry

For multiple pages in one immutable release, prepare the complete registries once and keep the snapshot in the host's release context:

import { prepareRuntimeRegistry, compilePageExecutionPlan } from "@page-engine/page-runtime-core";

const prepared = prepareRuntimeRegistry({ rendererRegistry, contractRegistry });
if (!prepared.ok) throw new Error(JSON.stringify(prepared.diagnostics));

const result = compilePageExecutionPlan({ manifest, registry: prepared.registry });
if (!result.ok) throw new Error(JSON.stringify(result.diagnostics));
console.log(result.plan);

RuntimeRegistrySnapshot is opaque, immutable and detached from the input objects. It retains all verified descriptors and private lookup indexes; unused entries are still fully validated. No global cache, I/O or clock is introduced. Every compilation still verifies the manifest's strict schema, digest, references, contracts and renderer identity/engine compatibility. Returned plans do not share mutable data with the snapshot or one another.

Snapshots belong to the core module instance that created them; they cannot be serialized, reconstructed or transferred to another worker/package copy. Re-prepare after a release/registry change and scope plan caches to that snapshot plus the manifest and engine compatibility identity. Dropping the host's references releases the snapshot; there is no dispose API.

The original three-input compilePageExecutionPlan call remains supported with its existing validation and diagnostics. Supplying both registry and raw registries, or an invalid/forged snapshot, fails with runtime.registry-invalid. See docs/page-engine-eng01-eng02.md in the repository for the implementation and validation record.

Applications rarely use this package directly: @page-engine/page-runtime-browser consumes execution plans in the browser and @page-engine/page-standalone-host drives the full lifecycle. Use it directly when you want to pre-compile plans or inspect the projection without a DOM.