Learn Hermes JS Engine - Scaling Teams & Release Automation

#Introduction

Episode 20 closed with performance budgets and observability. Now the problem is no longer technical, but social: how to make the whole team produce the same build, follow the same standards, and not repeat the same mistakes. A great Hermes project collapses if everyone has their own conventions.

Episode 21's roadmap: build conventions as a single source of truth, executable repro documents, onboarding developers to the Hermes runtime, documented performance guides, and consistent release automation.

#Build Conventions as a Single Source of Truth

Don't keep conventions in people's heads or in stale README comments. Store them as executable configuration in the repo. That way, whoever builds — human or CI — reads from the same source:

{
  "hermesFlags": ["-O", "-output-source-map"],
  "bytecodeVersion": 92,
  "minAndroidSdk": 23,
  "minNodeVersion": "20"
}

This file then becomes the single reference for validation scripts run at pre-commit and in CI:

Hermes configuration validation script

import fs from "node:fs";
 
const config = JSON.parse(fs.readFileSync("hermes.config.json", "utf8"));
const gradle = fs.readFileSync("android/app/build.gradle", "utf8");
 
for (const flag of config.hermesFlags) {
  if (!gradle.includes(flag)) {
    throw new Error(`flag ${flag} hilang di build.gradle`);
  }
}
 
console.log("Konfigurasi Hermes konsisten di seluruh repo");

#Repro Documents and Executable Conventions

Step-by-step repro documentation is needed, but even stronger is an executable repro. Write conventions as a script that fails with a clear message when violated:

#!/usr/bin/env bash
set -euo pipefail
 
node --version | grep -q "v20" || echo "gunakan Node 20"
bun install --frozen-lockfile
node scripts/verify-hermes-config.mjs
node scripts/verify-sourcemap.mjs index.android.hbc.map

Anyone who runs ./scripts/repro-build.sh from the repo directory gets exactly the same path as CI. This makes onboarding and cross-developer debugging much cheaper — the "it works on my machine" problem can be tested directly with one command.

#Onboarding Developers to the Hermes Runtime

New developers don't need to understand all of Hermes' internals to be productive. What they need is a clear path from setup to the first build:

• Provide an environment checklist (Node, JDK, Android SDK, Xcode) in the form of a doctor script.
• Show the basic debugging flow: JS logs, native logs, and where to get bytecode and source maps.
• Point out where the Hermes configuration lives and what's allowed to change — and what isn't.

#!/usr/bin/env bash
set -euo pipefail
 
check() {
  if command -v "$1" >/dev/null 2>&1; then
    echo "OK   $1 ($($1 --version 2>/dev/null | head -1))"
  else
    echo "MISS $1"
  fi
}
 
check node
check bun
check adb
check hbcdump

With a doctor script that checks the toolchain, an onboarding session that usually takes half a day can be cut down to a single command. Every obstacle a new developer hits also becomes feedback for improving the script — not for writing another wiki article.

#Documented Performance Guides and Build Standards

Standards that aren't written down will be forgotten. Document three short documents that live inside the repo:

• Performance guide: JavaScript patterns friendly to Hermes (recall episode 15), the no-allocation-in-hot-paths rule, and modularization rules.
• Build standards: approved Hermes flags, the bytecode production flow, and artifact naming rules.
• Upgrade policy: the process for bumping the Hermes and React Native versions, including regenerating bytecode and source maps.

Each document is linked from the PR template, so the author of a change is automatically reminded to read and follow the standard. That makes the standard part of the process, not decoration.

#Release Automation and the Review Checklist

With conventions locked down, releases can be automated. The semantic-release principle this repo itself uses — versions computed from conventional commits — applies equally to your Hermes app: every feat or fix commit determines the version bump, and CI running all validations is the gate.

The checklist that must be in the PR template:

• Hermes bytecode is produced successfully without errors.
• The source map is stored and matches the build version.
• Performance budgets aren't violated.
• Hermes configuration is consistent with hermes.config.json.
• The release is documented with rollback steps.

#Conclusion

Scaling a team isn't about adding more developers, but reducing variability between developers. With a single executable configuration, a repro script, a doctor for onboarding, and documentation linked into the release process, a new developer can produce the same artifact as a senior one.

The essentials to take home:

• Store build conventions as executable config files and scripts, not in people's heads.
• Give new developers an onboarding path in the form of a doctor script and a checklist.
• Document the performance guide, build standards, and upgrade policy inside the repo.
• Automate releases with conventional commits, but keep the same validation gates.
• Treat every onboarding problem as feedback for improving tooling, not for writing new docs.

In episode 22, the last episode of this series, we put it all together: Production Hardening & Best Practices — the final runtime checklist, memory security, and bundle integrity, plus continuous improvement strategies. See you there!