Runtime Compiler

3.2.0 verified Fri May 01 auth: no javascript

Universal compiler system for JavaScript code generation in multiple modes (default, build, hydrate). Version 3.2.0 is current stable. Ships TypeScript types. Key differentiator: build/hydrate mode separation for efficient asset compilation vs runtime hydration. Active development. Alternatives like Babel focus on transpilation, while runtime-compiler provides structured build-and-run orchestrations.

Common errors

error Error: Cannot find module 'runtime-compiler/config' ↓

cause Using an older version of the package that does not have the config subpath export.

fix

Upgrade to runtime-compiler@>=3.0.0 or import from the main package: import { isHydrating, onlyBuild } from 'runtime-compiler' (if available in your version).

error TypeError: isHydrating is not a function ↓

cause Using isHydrating as a boolean (e.g., if (isHydrating)) instead of calling it as a function.

fix

Change to if (isHydrating()) to invoke the function.

error SyntaxError: The requested module 'runtime-compiler' does not provide an export named 'default' ↓

cause Trying to import a default export when only named exports are available in that version.

fix

Use named import: import { compile } from 'runtime-compiler' instead of import compiler from 'runtime-compiler'.

Warnings

breaking Version 3.0 changed the config exports from default to named. Previously exported as default object, now must destructure. ↓

fix Change import from 'import config from 'runtime-compiler/config' to 'import { isHydrating, onlyBuild } from 'runtime-compiler/config'

gotcha isHydrating and onlyBuild are functions, not boolean constants. Directly using them as booleans will always be truthy. ↓

fix Invoke as functions: if (isHydrating()) instead of if (isHydrating)

deprecated The 'build' and 'hydrate' mode literals are deprecated in favor of the config functions. Using string comparisons may break in future versions. ↓

fix Use isHydrating() or onlyBuild() from 'runtime-compiler/config' instead of checking process.env.COMPILER_MODE

gotcha In Node.js ESM, top-level process.env checks for mode are not available until import phase; the config functions are safe alternatives. ↓

fix Always use the config functions to avoid undefined behavior.

Install

npm install runtime-compiler

yarn add runtime-compiler

pnpm add runtime-compiler

Imports

isHydrating

wrong

import { isHydrating } from 'runtime-compiler'

correct

import { isHydrating } from 'runtime-compiler/config'

Must be imported from 'runtime-compiler/config' subpath, not the main package.

onlyBuild

wrong

import onlyBuild from 'runtime-compiler/config'

correct

import { onlyBuild } from 'runtime-compiler/config'

Named export, not default. Using default import will result in undefined.

runtime-compiler (default)

wrong

const compiler = require('runtime-compiler')

correct

import compiler from 'runtime-compiler'

Package is ESM-only. Use import syntax only.

Quickstart

Shows how to import and use the config utility functions (isHydrating, onlyBuild) to determine the current compiler mode, and a basic compile example.

import { isHydrating, onlyBuild } from 'runtime-compiler/config';

if (isHydrating()) {
  console.log('Running in hydrate mode - only executing, not building.');
} else if (onlyBuild()) {
  console.log('Running in build mode - only building, not executing.');
} else {
  console.log('Running in default mode - building and executing.');
}

// Example with compiler mode
import compiler from 'runtime-compiler';
const result = compiler.compile('someSourceCode');
console.log(result);