Belajar Hermes JS Engine - Configuration Management & Build Validation

#Pendahuluan

Episode 10 menutup rantai observability: source maps, stack trace yang readable, dan telemetry yang rapi. Sekarang kita mundur satu langkah ke sisi yang tidak terlihat: bagaimana memastikan setiap build menghasilkan bytecode yang sama, tervalidasi, dan layak rilis. Tanpa ini, source map yang bagus pun jadi kebohongan kalau build-nya tidak bisa diulang.

Roadmap episode 11: menyimpan konfigurasi Hermes untuk build reproducibility, memvalidasi output build dengan CI checks, lalu mengintegrasikan semuanya dengan linting serta release pipelines.

#Konfigurasi Hermes sebagai Sumber Tunggal

Masalah klasik tim: developer A membangun dengan flag -O, developer B lupa, dan bytecode yang dihasilkan berbeda di perangkat mereka. Solusinya sederhana — konfigurasi Hermes harus menjadi kode yang di-commit, bukan perintah yang dihafal. Di React Native, flag kompiler disimpan di build.gradle:

react {
  hermesFlags = [
    "-O",
    "-output-source-map",
  ]
}

Untuk workload embeddable di luar React Native, simpan perintah kompilasi dalam skrip yang dipanggil bersama, misalnya scripts/compile.sh. Jangan pernah menjalankan hermesc secara ad hoc tanpa dokumentasi flag. Kalau konfigurasi berubah, perubahan itu harus terlihat di code review seperti perubahan kode lain.

Sumber kebenaran tunggal ini yang membuat build reproducible: selama semua orang memakai file yang sama, bytecode yang dihasilkan identik.

#Build Reproducibility

Reproducibility tidak cukup dengan flag yang sama. Versi toolchain juga harus terkunci:

• Pin versi Hermes: ikuti versi Hermes yang disematkan di React Native yang dipakai, atau pin commit hermesc untuk embedding custom. Bytecode terkunci ke versi engine — ingat pelajaran dari episode 13 nanti.
• Lockfile: bun.lock atau package-lock.json wajib ikut repo, dan instalasi CI memakai mode frozen, misalnya bun install --frozen-lockfile.
• Stempel versi: simpan versi build ke dalam metadata konfigurasi native, supaya setiap artefak bisa ditelusuri balik ke commit asalnya.

hermesc -version
node --version
bun --version

Jalankan ketiga perintah di atas saat CI mulai, lalu catat output-nya sebagai bagian dari laporan build. Ketika bug muncul, kalian bisa membedakan "masalah di kode" dan "masalah di toolchain" hanya dari catatan ini.

#Validasi Output Build di CI

Build yang sukses belum tentu output-nya benar. CI harus memvalidasi artefak sebelum dianggap layak. Pemeriksaan minimum:

• Bundle bytecode ada dan tidak kosong.
• Source map ada dan pasangannya valid.
• Bytecode bisa dibaca tool pemeriksa, misalnya hbcdump.
• Ukuran bundle tidak melonjak melewati budget yang disepakati.

Skrip validasi bisa sesederhana ini:

set -e
test -s dist/index.android.bundle
test -s dist/index.android.map
hbcdump -summary dist/index.android.bundle

Kalau salah satu pemeriksaan gagal, skrip keluar dengan kode non-nol dan CI pun merah. Membuat pemeriksaan otomatis seperti ini jauh lebih murah daripada menemukan bundle rusak di tangan user.

#CI Checks dan Pipeline

Integrasi dilakukan di workflow. Berikut contoh langkah-langkah yang biasa dipakai dalam pipeline build Hermes:

name: hermes-build-check
 
on:
  pull_request:
  push:
    branches: [main, staging]
 
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Install dependencies
        run: bun install --frozen-lockfile
      - name: Build bundle
        run: bun run build:content
      - name: Validate artifacts
        run: bash scripts/validate-artifacts.sh
      - name: Upload source maps
        run: bash scripts/upload-sourcemaps.sh

Perhatikan bahwa setiap pull request sudah melewati alur yang sama dengan release: install terkunci, build, validasi, dan upload source map. Ini membuat release pipeline tidak punya kejutan — hal yang biasanya baru muncul justru di langkah terakhir sebelum rilis.

#Integrasi dengan Linting dan Release Pipelines

Konfigurasi build juga perlu dijaga lewat linting. Beberapa praktik yang terbukti:

• Lint konfigurasi: buat aturan yang menolak hermesFlags yang tidak diizinkan atau source map yang hilang pada build release.
• Checklist wajib di release: commit konvensional, versi semantik yang benar, dan artefak bytecode yang tervalidasi menjadi prasyarat sebelum tag rilis dibuat.
• Gerbang rilis: semua pemeriksaan CI harus hijau sebelum tag rc atau versi stabil bisa dipromosikan.

Release pipeline yang baik bersifat deterministik: urutan yang sama dijalankan, artefak yang sama dihasilkan, dan keputusan layak rilis diambil oleh CI, bukan oleh ingatan manusia.

#Penutup

Dengan konfigurasi yang disimpan sebagai kode, toolchain yang terkunci, dan CI yang memvalidasi setiap artefak, kalian punya fondasi build yang bisa diulang dan dipercaya. Linting dan gerbang release menutup siklusnya: tidak ada yang rilis tanpa melewati pemeriksaan yang sama.

Inti yang harus dibawa pulang:

• Konfigurasi Hermes disimpan sebagai kode, bukan perintah yang dihafal di kepala.
• Reproducibility butuh flag konsisten, versi toolchain terkunci, dan lockfile frozen.
• CI wajib memvalidasi artefak: bundle ada, source map valid, dan bytecode bisa dibaca.
• Upload source map dilakukan di dalam pipeline yang sama dengan build, sebelum aplikasi rilis.
• Gerbang release diputuskan oleh CI yang hijau, bukan oleh ingatan manusia.

Di episode 12 kita masuk fase baru: Secure Runtime Practices. Kalian akan belajar memuat bundel JavaScript dengan aman, menghindari remote code execution dan eval yang tidak aman, serta mitigasi praktis untuk aplikasi mobile dan edge. Sampai jumpa!