The problem
Sometimes you want Aero templating outside a full Aero app and Vite runtime. Examples include rendering HTML in scripts or tools, generating email-like output from templates, or using Aero in a Node ESM service without booting Vite. Without a dedicated entrypoint, you stitch compiler output, module loading, and runtime rendering together yourself.What this looks like without Aero helpers
You compile template source, then still need to load generated module code, bridge imports, and feed it into the runtime context yourself.How Aero helps
@aero-js/core/runtime/standalone provides an ESM-first execution bridge and one-shot render helpers:
loadCompiledTemplateModule(...)renderTemplate(...)
Imports
One-shot rendering
UserenderTemplate(...) when you have HTML source and want rendered output directly.
Options
templateSource(required): HTML template sourceroot(required): project root for import resolutionimporter(required): virtual or real source path used as importer for relative importsresolvePath(optional): alias and path resolver(specifier, importer) => stringglobals(optional): values registered viaAero.global(name, value)input(optional): forwarded toAero.render(...)
Load precompiled module source
UseloadCompiledTemplateModule(...) when compilation and execution are separate steps.
pageModule can then be registered or rendered through the runtime in advanced flows.
Boundaries and constraints
- Standalone helpers are currently ESM-first.
rootandimporterare required for import resolution.- Bundled client-script workflows still belong to the normal Aero and Vite path.
- For normal app runtime, keep using standard Aero entrypoints; standalone is for out-of-band execution flows.