Belajar Hermes JS Engine - Scaling Teams & Release Automation

#Pendahuluan

Episode 20 menutup dengan performance budgets dan observability. Sekarang masalahnya bukan teknis lagi, melainkan sosial: bagaimana membuat seluruh tim memproduksi build yang sama, mematuhi standar, dan tidak mengulangi kesalahan yang sama. Sebuah project Hermes yang hebat akan runtuh jika setiap orang punya konvensi sendiri.

Roadmap episode 21: konvensi build sebagai sumber kebenaran tunggal, dokumen repro yang bisa dieksekusi, on-boarding developer ke Hermes runtime, panduan performa yang terdokumentasi, dan release automation yang konsisten.

#Konvensi Build sebagai Sumber Kebenaran Tunggal

Jangan menaruh konvensi di kepala orang atau di komentar README yang sudah usang. Simpan sebagai konfigurasi yang bisa dieksekusi di repo. Dengan begitu, siapa pun yang membangun — manusia atau CI — membaca dari sumber yang sama:

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

File ini lalu menjadi referensi tunggal bagi skrip validasi yang dijalankan di pre-commit dan CI:

Skrip validasi konfigurasi Hermes

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");

#Dokumen Repro dan Konvensi yang Bisa Dieksekusi

Dokumentasi repro langkah-demi-langkah memang perlu, tapi yang lebih kuat adalah repro yang bisa dijalankan. Tulis konvensi sebagai skrip yang akan gagal dengan pesan jelas ketika dilanggar:

#!/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

Siapa pun yang menjalankan ./scripts/repro-build.sh dari direktori repo mendapatkan jalur yang persis sama dengan CI. Ini membuat on-boarding dan debugging antar developer jauh lebih murah — masalah "di mesin saya jalan" bisa langsung diuji dengan satu perintah.

#Onboarding Developer ke Hermes Runtime

Developer baru tidak perlu memahami seluruh internal Hermes untuk produktif. Yang mereka butuhkan adalah jalur yang jelas dari setup sampai build pertama:

• Berikan daftar periksa lingkungan (Node, JDK, Android SDK, Xcode) dalam bentuk script doctor.
• Perlihatkan alur debugging dasar: log JS, log native, dan tempat mengambil bytecode serta source map.
• Tunjukkan di mana konfigurasi Hermes berada dan apa yang boleh diubah — dan apa yang tidak boleh.

#!/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

Dengan script doctor yang memeriksa toolchain, sesi on-boarding yang biasanya memakan setengah hari bisa dipangkas menjadi satu perintah. Setiap kendala yang ditemukan developer baru juga menjadi masukan untuk memperbaiki script — bukan untuk membuat artikel wiki lagi.

#Panduan Performa dan Standar Build yang Terdokumentasi

Standar yang tidak ditulis akan dilupakan. Dokumentasikan tiga dokumen singkat yang hidup di dalam repo:

• Panduan performa: pola JavaScript yang ramah Hermes (recall episode 15), larangan alokasi di hot path, dan aturan modularisasi.
• Standar build: flag Hermes yang disetujui, alur pembuatan bytecode, dan aturan penamaan artefak.
• Kebijakan upgrade: proses menaikkan versi Hermes dan React Native, termasuk regenerasi bytecode serta source map.

Setiap dokumen ditautkan ke PR template, sehingga penulis perubahan otomatis diingatkan untuk membaca dan mematuhi standar. Ini menjadikan standar bagian dari proses, bukan pajangan.

#Release Automation dan Review Checklist

Dengan konvensi yang terkunci, rilis bisa diotomatiskan. Prinsip semantic-release yang dipakai repo ini sendiri — versi dihitung dari conventional commits — berlaku sama untuk aplikasi Hermes kalian: setiap commit feat atau fix menentukan kenaikan versi, dan CI yang menjalankan semua validasi menjadi gerbangnya.

Checklist yang harus ada di PR template:

• Bytecode Hermes berhasil diproduksi tanpa error.
• Source map disimpan dan cocok dengan versi build.
• Budget performa tidak dilanggar.
• Konfigurasi Hermes konsisten dengan hermes.config.json.
• Rilis didokumentasikan dengan langkah rollback.

#Penutup

Scaling tim bukan soal menambah jumlah developer, melainkan mengurangi variabilitas antar developer. Dengan konfigurasi tunggal yang bisa dieksekusi, skrip repro, doctor untuk on-boarding, dan dokumentasi yang tertaut ke proses rilis, satu developer baru bisa menghasilkan artefak yang sama dengan developer senior.

Inti yang harus dibawa pulang:

• Simpan konvensi build sebagai file konfigurasi dan skrip yang bisa dieksekusi, bukan di kepala orang.
• Berikan developer baru jalur on-boarding dalam bentuk script doctor dan checklist.
• Dokumentasikan panduan performa, standar build, dan kebijakan upgrade di dalam repo.
• Otomatiskan rilis dengan conventional commits, tapi pertahankan gerbang validasi yang sama.
• Jadikan setiap masalah on-boarding sebagai umpan balik untuk memperbaiki tooling, bukan dokumen baru.

Di episode 22, episode terakhir series ini, kita menyusun semuanya: Production Hardening & Best Practices — checklist akhir runtime, keamanan memori, dan integritas bundel, plus strategi peningkatan berkelanjutan. Sampai jumpa!