Laravel 13.36.0 Rilis 14 Oktober 2026: Rule:: Builders Lengkap, DB::olap() & Dampaknya untuk Source Code Kamu

Laravel 13.36.0 dirilis pada 14 Oktober 2026 dengan empat perubahan penting: Rule:: builders kini tersedia untuk semua rule validasi yang sebelumnya hanya bisa ditulis sebagai string, DB::olap() untuk query besar di PlanetScale/Vitess, opsi reset koneksi database sticky antar queue job, dan broadcast Mercure yang kini berjalan sinkron secara default. Ini rilis minor dalam seri 13.x — tanpa breaking change yang diumumkan — sehingga aman untuk diadopsi source code Laravel yang sudah berjalan.

Kabar ini dilaporkan Laravel News pada 14 Oktober 2026, hanya selisih sekitar satu minggu dari rilis Laravel 13.35.0 yang sebelumnya juga kami bahas. Ritme rilis mingguan Laravel memang sedang kencang: sejak Laracon US 2026, hampir setiap minggu ada fitur praktis yang mendarat di 13.x.

Ringkasan perubahan Laravel 13.36.0

Apa yang baru di Laravel 13.36.0?

Bagaimana cara memakai Rule:: builders untuk semua rule validasi?

Ini perubahan paling terasa untuk developer sehari-hari. Kontributor @ericmp33 menambahkan method Rule:: untuk setiap rule validasi yang sebelumnya hanya punya sintaks string — seperti required_with, accepted_if, url, uuid, dan distinct. Sekarang validasi bisa ditulis sepenuhnya dengan builder yang bisa di-autocomplete IDE:

Bandingkan dengan cara lama yang masih banyak dipakai di source code yang beredar:

Selain ergonomis, ada perbaikan bug halus yang ikut selesai: rule yang menerima nama field atau nilai kini mengembalikan objek yang meneruskan parameter sebagai array — sehingga nilai yang mengandung koma tidak lagi terpecah menjadi dua nilai. Ini bug klasik pada rule string seperti in:foo,bar yang diam-diam bisa lolos dari perhatian.

Catatan jujur: ini murni perbaikan sintaks, bukan perubahan perilaku validasi. Rule tanpa parameter seperti Rule::required() dan Rule::nullable() tetap mengembalikan string biasa. Kalau source code kamu sudah berjalan stabil dengan string rule, tidak ada keharusan migrasi — tapi untuk kode baru, builder jauh lebih aman dari typo. Dokumentasi lengkapnya ada di laravel.com/docs/validation.

Apa itu DB::olap() dan kapan harus dipakai?

Kontributor Jack Bayliss menambahkan method olap() dan isVitess() pada koneksi MySQL. PlanetScale berjalan di atas Vitess, yang membatasi query pada workload OLTP default — satu query hanya bisa mengembalikan maksimal 100.000 baris. Untuk laporan agregat besar, itu masalah nyata.

DB::olap() mengganti workload ke OLAP selama callback berjalan, lalu mengembalikannya seperti semula:

Method ini mengatur workload pada koneksi read maupun write. Kabar baiknya: pada database yang bukan Vitess, olap() hanya menjalankan callback tanpa efek apa pun — jadi kode yang sama tetap jalan di MySQL lokal saat development.

Batasan yang perlu dipahami: ini hanya relevan jika database produksi kamu PlanetScale atau Vitess. Untuk query kecil sehari-hari, tidak ada alasan memakai DB::olap() — overhead ganti workload tidak sebanding dengan manfaatnya. Dan method ini khusus koneksi MySQL; database lain tidak terpengaruh.

Mengapa koneksi sticky antar queue job perlu di-reset?

Ini perbaikan untuk bug operasional yang sulit dilacak. Ketika opsi sticky aktif pada koneksi database read/write, sebuah operasi write membuat semua read berikutnya diarahkan ke koneksi write. Masalahnya: queue worker adalah satu proses panjang — satu job yang melakukan write bisa membuat read dari semua job berikutnya di worker yang sama ikut diarahkan ke koneksi write, membebani database utama tanpa disadari.

Solusinya adalah flag opt-in yang me-reset state sebelum setiap job:

Flag ini mati secara default, dan itu keputusan yang tepat: sebuah job bisa saja bergantung pada kemampuan membaca data yang ditulis job sebelumnya dalam worker yang sama. Aktifkan hanya jika aplikasi kamu memakai koneksi read/write terpisah (misalnya read replica) dan traffic queue-nya tinggi. Untuk panduan queue secara umum, lihat juga artikel kami tentang pengiriman email otomatis dengan queue.

Apa yang berubah pada broadcast Mercure?

Kévin Dunglas mengubah broadcaster Mercure agar mempublikasikan event langsung alih-alih lewat queue. Event yang hanya menargetkan koneksi Mercure kini berperilaku seperti ShouldBroadcastNow; event yang juga menargetkan koneksi lain tetap di-queue seperti biasa.

Kalau kamu ingin perilaku lama, cukup set:

Perlu dicatat: mode async membutuhkan url Mercure karena queue worker mempublikasikan lewat HTTP. PR yang sama juga memperbaiki crash Artisan command ketika BROADCAST_CONNECTION=mercure tanpa url yang diset dan fungsi FrankenPHP mercure_publish() tidak tersedia — relevan buat kamu yang menjalankan Laravel Octane/FrankenPHP.

Perubahan ini berpotensi mengubah perilaku aplikasi yang sudah memakai Mercure: event yang tadinya asinkron kini sinkron. Kalau latency broadcast penting buat kamu, uji dulu sebelum update.

Bagaimana cara upgrade ke Laravel 13.36.0 dengan aman?

Karena ini rilis minor 13.x, tidak ada breaking change yang diumumkan. Alur upgrade amannya standar:

Checklist tambahan khusus rilis ini:

1. Cek pemakaian Mercure. Jika aplikasi memakai broadcast Mercure, putuskan: biarkan sinkron (default baru) atau set MERCURE_ASYNC=true untuk mempertahankan perilaku lama.
2. Evaluasi flag sticky connection. Hanya aktifkan Worker::$flushStickyConnections = true jika kamu memakai read/write split dan paham risikonya.
3. Uji di staging dulu. Terutama job queue dan fitur broadcast — dua area yang perilakunya berubah.
4. Untuk penjual source code: update composer.lock, catat versi di changelog produk, dan pastikan demo berjalan di 13.36 sebelum mengklaim kompatibel. Lihat panduan upgrade Laravel dari versi lama bila basis kode kamu masih tertinggal beberapa versi.

Pertanyaan yang sering ditanyakan

Apakah Laravel 13.36.0 wajib di-install segera? Tidak wajib. Ini rilis minor berisi fitur dan perbaikan, bukan rilis keamanan kritis. Update saat kamu siap, setelah uji di staging.

Apakah ada breaking change di 13.36.0? Tidak ada yang diumumkan. Satu-satunya perubahan perilaku adalah broadcast Mercure yang kini sinkron secara default — bisa dikembalikan dengan MERCURE_ASYNC=true.

Apakah Rule:: builders menggantikan string rule sepenuhnya? Tidak. Keduanya tetap didukung. Builder hanya memberi alternatif yang lebih aman dari typo dan didukung autocomplete IDE.

Kapan saya butuh DB::olap()? Hanya jika database produksi memakai PlanetScale/Vitess dan kamu menjalankan query agregat yang mengembalikan lebih dari 100.000 baris. Untuk MySQL biasa, method ini tidak berpengaruh.

Apakah flag Worker::$flushStickyConnections aman diaktifkan? Aman jika job-job kamu independen. Berisiko jika sebuah job bergantung membaca data yang ditulis job sebelumnya dalam worker yang sama — karena reset memutus rantai itu.

Apakah perubahan ini memengaruhi Laravel AI SDK atau fitur AI? Tidak langsung. Rilis ini fokus pada validasi, database, queue, dan broadcasting. Untuk kabar AI di ekosistem Laravel, lihat artikel Laravel AI SDK 1.2.1.

Di mana saya bisa membaca changelog resminya? Di laravel-news.com/laravel-13-36-0 dan halaman rilis laravel/framework di GitHub.

Artikel ini disusun berdasarkan laporan Laravel News tertanggal 14 Oktober 2026. Ritme rilis Laravel 13.x sedang cepat — pantau terus kanal News Kios Koding untuk ringkasan tiap rilis penting dalam Bahasa Indonesia.