Coralite v0.35.0 Released
Coralite v0.35.0 is now available. This release delivers major enhancements for enterprise-scale web builds, introducing an overhauled multi-pass production memory architecture designed to scale to over 1 million pages. It also modernizes our plugin system with a two-phase curried exports API, native context injection via this, and stronger internal engine boundaries.
Production Memory Overhaul for 1M+ Pages #
To support massive multi-page web deployments, we have overhauled production memory management with a memory-efficient multi-pass build architecture. In production mode, Coralite now performs on-demand parsing rather than retaining heavily nested HTML AST nodes for all pages in memory throughout the build lifecycle.
This optimization comprises several core mechanism shifts:
- Discovery Phase: Scans pages to extract metadata while immediately discarding heavy AST nodes.
- On-Demand Parsing: Re-parses HTML files just before rendering, garbage collecting the AST tree as soon as the rendering phase completes.
- Build Streaming: The
build()API now supports streaming results, allowing builders to handle pages sequentially without array accumulation.
Tests verify stable memory consumption at approximately 22MB for 10,000 pages in production mode, laying the foundation for scaling builds to over 1,000,000 pages.
Modernized Plugin Exports and Context Binding #
We have renamed the plugin method property to exports and re-architected its execution flow. The exports signature has transitioned to an object of two-phase curried functions, allowing for clean context injection and more explicit server-side build lifecycle integration.
Plugin context is now bound natively via this instead of being passed as a trailing argument. A recursive traversal mechanism automatically binds context down to nested export structures. This ensures that server-side utilities have direct access to context properties like this.app.
Here is an example demonstrating the new two-phase curried export format inside a plugin definition:
definePlugin({
name: 'custom-data-fetcher',
exports() {
// Phase 1: Context injection
const ctx = this;
return {
// Phase 2: Curried function execution
async fetchJson(url) {
return ctx.app.fetch(url);
}
};
}
});
These plugin exports are exposed via virtual modules, which can be imported directly into the script sections of your components:
<template>
<div>{{ data.message }}</div>
</template>
<script>
import { fetchJson } from 'virtual:custom-data-fetcher'
export default {
async data () {
const response = await fetchJson('/api/resource')
return { data: response }
}
}
</script>
Hardening Internal Engine Boundaries #
Because the main Coralite instance is exposed to plugins during build phases, we have introduced a safety layer using Object.defineProperties. All internal instance properties (such as _scriptManager, _plugins, and _renderQueues) and prototype methods starting with an underscore (_) are now configured as non-writable, non-configurable, and non-enumerable. This prevents external plugin logic from accidentally mutating or polluting internal engine states.
Benchmark Script CLI Selections #
To improve developer workflow when profiling performance, the benchmark runner (run-benchmarks.js) has been updated to use commander for argument parsing. You can now execute specific benchmark suites by providing their file names as CLI arguments:
node run-benchmarks.js memory parsing
Breaking Changes #
- Plugin Exports Two-Phase Currying: Plugin
exportssignature has changed from a single function to an object of two-phase curried functions. - Removal of /plugins Subpath: Imports must be updated, as the
/pluginssubpath has been removed from core exports. - Removal of Deprecated definePlugin Method: The deprecated
definePluginmethod on the state plugin has been removed.
How to Upgrade #
To upgrade to the latest version, update your project dependencies:
npm install coralite@0.35.0
npm install coralite-scripts@0.35.0
