Ruff 0.17.4: Aturan Keamanan Baru dan Sembilan Optimasi

Ruff 0.17.4 dirilis 5 November 2026, sembilan hari setelah 0.17.3 yang keluar 27 Oktober 2026, dan berisi dua aturan preview baru, empat perbaikan bug, serta sembilan butir optimasi performa menurut catatan rilis resmi. Tidak ada perubahan besar pada antarmuka: sebagian besar pekerjaan ada di mesin lint dan formatter, termasuk perbaikan panic saat membaca berkas berawalan BOM dan penggunaan Bloom filter untuk pencarian komentar formatter.

TL;DR

• Ruff 0.17.4 keluar 5 November 2026, menggantikan 0.17.3 yang terbit 27 Oktober 2026.
• Dua aturan preview baru: perbaikan G004 yang lebih aman, dan aturan keamanan tarfile-ignore-zeros-true.
• Perbaikan penting: panic pada berkas berawalan BOM di renderer diagnostik sudah hilang.
• Sembilan butir performa, termasuk Bloom filter untuk pencarian komentar dan buffer konkret untuk penulisan biasa.
• Perubahan CLI kecil: NO_COLOR kini diprioritaskan dan CLICOLOR=0 dihormati.

Kenapa rilis kecil seperti 0.17.4 tetap layak dipasang?

Karena nilai utama rilis ini ada di stabilitas, bukan fitur. Dua dari empat perbaikan bug menyentuh hal yang bisa menghentikan proses: panic pada berkas berawalan BOM dan kesalahan parsing pada raise polos sebelum titik koma. Kalau pipeline lint Anda berjalan di banyak repositori, satu berkas yang memicu panic bisa membuat job gagal total, bukan sekadar melaporkan satu temuan.

Perbaikan BOM itu masuk lewat pull request 30017 dan terjadi di renderer diagnostik. Artinya masalahnya bukan pada parsing, melainkan pada tahap menampilkan hasil, dan itulah jenis bug yang paling menjengkelkan karena muncul setelah lint selesai bekerja. Untuk repositori yang menyimpan berkas hasil ekspor dari alat lain, kemungkinan bertemu BOM cukup besar, jadi perbaikan ini praktis.

Perbaikan berikutnya menyangkut sintaks. raise polos sebelum titik koma kini diterima, dan pengenal match boleh muncul setelah titik koma. Keduanya terlihat sepele, tetapi berkas hasil generate yang memadatkan beberapa pernyataan dalam satu baris adalah tempat bug semacam ini biasanya bersembunyi. Kalau repositori Anda punya kode hasil generator, jalankan versi ini pada seluruh isinya, bukan hanya pada kode yang ditulis tangan.

Apa yang masuk jalur preview di versi ini?

Ada dua butir di bagian preview features. Yang pertama menyentuh aturan G004 dari kelompok flake8-logging-format: perbaikannya diubah agar tidak mengubah perilaku dan tidak menghasilkan kesalahan sintaks. Ini penting karena autofix yang salah bisa merusak kode yang sebenarnya benar, dan kerusakan seperti itu sering lolos karena orang percaya pada hasil fix otomatis.

Butir kedua menambahkan aturan keamanan tarfile-ignore-zeros-true. Namanya cukup jelas: aturan ini menyasar pemakaian ekstraksi arsip tar dengan opsi yang mengabaikan penanda akhir. Kelompok aturan keamanan memang tempat Ruff menaruh pemeriksaan untuk pola berisiko, dan penambahan ini masuk jalur preview lebih dulu sebelum dianggap stabil.

Kategori	Isi di 0.17.4	Dampak ke pipeline
Preview	Perbaikan G004, aturan tarfile-ignore-zeros-true	Hanya aktif kalau Anda memakai jalur preview
Bug fix	Panic BOM, raise sebelum titik koma, match setelah titik koma, SIM102	Job lint lebih jarang gagal karena crash atau false positive
Performa	Sembilan butir, termasuk Bloom filter dan buffer konkret	Waktu lint turun pada repositori besar
CLI	NO_COLOR diprioritaskan, CLICOLOR=0 dihormati	Keluaran log CI lebih bersih dan mudah dibaca mesin

Perlu diingat bahwa aturan di jalur preview bisa berubah lagi di rilis berikutnya. Kalau tim Anda memakai preview, jadwalkan pemeriksaan setiap kali versi baru keluar, karena hasil lint bisa berubah tanpa Anda mengubah konfigurasi apa pun. Sebaliknya, kalau hanya memakai aturan stabil, rilis ini bisa dipasang tanpa mengubah daftar rule sama sekali.

Perbaikan mana yang paling terasa di repositori besar?

Yang paling terasa bukan satu perbaikan tunggal, melainkan kumpulan optimasi di jalur formatter. Ada dua butir yang menyentuh hal yang sama dari dua sisi: pemakaian Bloom filter untuk pencarian komentar formatter, dan pengurangan overhead pemotongan sumber. Keduanya mengurangi pekerjaan yang dilakukan berulang pada setiap berkas, dan itulah pola optimasi yang biasanya berdampak paling besar pada waktu eksekusi keseluruhan.

Butir lain menyentuh analisis: pengumpulan pernyataan return memakai visitor yang lebih sempit, nama terqualifikasi milik fungsi yang dipanggil dipakai ulang lintas aturan, dan perbandingan nilai untuk kunci kamus berulang ditunda pada F601 serta F602. Semua ini adalah penghematan alokasi dan pemindaian, yang efeknya kecil per berkas tetapi menumpuk saat ribuan berkas diproses.

Ada juga satu optimasi yang sangat spesifik: pemeriksaan karakter string tidak valid dilewati kalau sumbernya memang tidak mengandung karakter semacam itu. Pola ini menunjukkan pendekatan yang sehat, yaitu membayar biaya pemeriksaan hanya ketika ada indikasi bahwa pemeriksaan itu perlu. Bagi pengguna, hasilnya sederhana: lint selesai lebih cepat tanpa perubahan konfigurasi.

Bagaimana cara mengukur dampaknya di proyek sendiri?

Ukur waktu lint pada versi lama dan baru di repositori yang sama, dengan cache dibersihkan dan jumlah pekerjaan yang setara. Jangan membandingkan waktu pada repositori berbeda, dan jangan membandingkan run pertama dengan run kedua, karena cache bisa membuat angka kedua terlihat jauh lebih baik tanpa ada perubahan nyata pada perkakasnya.

Langkah minimal yang bisa dijalankan: catat waktu ruff check pada seluruh repositori dengan versi lama, ulangi dengan versi baru, lalu lakukan tiga kali dan pakai nilai tengahnya. Kalau selisihnya kecil, itu wajar, karena optimasi di rilis ini bersifat kumulatif. Yang lebih penting adalah memastikan jumlah temuan tidak berubah, kecuali Anda memang mengaktifkan aturan preview baru.

Untuk formatter, ukur juga pada berkas yang punya banyak komentar, karena di situlah perubahan Bloom filter paling terasa. Kalau hasil format berbeda dari versi lama pada berkas yang sama, jangan langsung menyalahkan versi baru. Cek dulu apakah ada aturan preview yang aktif, karena perbaikan G004 sengaja dibuat agar tidak mengubah perilaku, dan perubahan hasil yang tidak diharapkan biasanya berasal dari konfigurasi.

Perubahan tampilan diagnostik dan karakter nonprinting

Ada satu perubahan di bagian rule changes: karakter nonprinting sekarang ditampilkan lebih banyak di diff saran perbaikan. Tujuannya jelas, yaitu membuat orang bisa melihat karakter tak terlihat yang selama ini tersembunyi di dalam baris kode. Karakter seperti tab, spasi tak terputus, atau karakter kendali sering jadi penyebab bug yang sulit dijelaskan, dan menampilkannya di diff membuat perbaikan bisa dipahami tanpa menebak.

Konsekuensinya untuk pipeline: kalau Anda membandingkan keluaran lint antar versi, beberapa baris akan terlihat berbeda meski temuannya sama. Ini bukan regresi, melainkan perubahan representasi. Sistem yang membaca keluaran berbasis format terstruktur, misalnya keluaran JSON, seharusnya tidak terpengaruh, tetapi skrip yang menyalin teks mentah dari terminal bisa jadi bingung.

Perubahan kecil semacam ini juga relevan untuk tim yang memakai Ruff di editor. Diff yang lebih jujur soal karakter tersembunyi mengurangi kasus di mana sebuah perbaikan diterapkan tetapi masalah tetap muncul, karena masalahnya justru ada di karakter yang tidak terlihat. Kalau tim Anda sering berurusan dengan berkas hasil salin tempel dari web, perubahan ini akan terasa berguna.

Pengaruh perubahan CLI pada log CI

Dua butir di bagian CLI menyentuh variabel lingkungan pewarnaan: NO_COLOR kini diprioritaskan, dan CLICOLOR=0 dihormati. Bagi sebagian orang ini detail sepele, tetapi bagi pipeline yang menyimpan log sebagai artefak, keluaran tanpa kode warna jauh lebih mudah dibaca ulang dan dicari. Log berwarna yang disimpan ke berkas penuh dengan karakter kendali yang mengganggu pencarian teks.

Perubahan ini juga menutup sumber kebingungan yang klasik: perilaku berbeda antara terminal interaktif dan runner CI. Kalau Anda selama ini memaksa keluaran polos dengan trik tambahan, misalnya mem-pipe keluaran ke perintah lain, sekarang cukup mengatur satu variabel lingkungan. Yang perlu diperiksa adalah urutan prioritas, karena NO_COLOR sekarang menang, dan itu berarti konfigurasi lama yang mengandalkan variabel lain bisa berubah hasilnya.

Perubahan dokumentasi juga layak dicatat karena menyangkut integrasi CI: nilai bawaan version dan src untuk ruff-action dikoreksi sesuai perilaku sebenarnya. Kalau pipeline Anda memakai action tersebut tanpa menentukan versi secara eksplisit, baca ulang dokumentasinya setelah upgrade. Menentukan versi secara eksplisit adalah kebiasaan yang lebih baik, karena membuat hasil build bisa direproduksi.

Checklist adopsi untuk tim yang memakai Ruff di CI

• Pin versi Ruff di pipeline, jangan memakai versi terbaru secara otomatis.
• Jalankan 0.17.4 pada seluruh repositori, bukan hanya pada direktori yang sering diubah.
• Bandingkan jumlah temuan dengan versi lama dan catat selisihnya di tiket perubahan.
• Kalau memakai preview, baca daftar aturan preview yang aktif sebelum menaikkan versi.
• Pastikan variabel pewarnaan diatur eksplisit supaya log CI bisa dicari.
• Ukur waktu lint sebelum dan sesudah pada repositori yang sama, dengan cache dibersihkan.

Satu catatan soal mem-pin versi: pin yang terlalu ketat membuat tim melewatkan perbaikan bug seperti panic BOM di rilis ini, sementara pin yang terlalu longgar membuat hasil lint berubah tanpa persetujuan siapa pun. Titik seimbangnya adalah pin versi penuh dan jadwalkan pembaruan berkala, misalnya setiap bulan, dengan tiket perubahan yang mencatat perbedaan jumlah temuan.

Untuk repositori yang memakai Ruff bersama alat lain, perhatikan juga urutan eksekusi. Menjalankan formatter sesudah lint membuat diff perbaikan bisa tidak relevan lagi. Urutan yang lebih masuk akal adalah format lebih dulu, lalu lint, lalu perbaikan otomatis, dan terakhir lint sekali lagi untuk memastikan tidak ada temuan baru yang muncul akibat perbaikan itu sendiri.

Catatan untuk pengguna editor dan pre-commit

Kalau Ruff dipasang di pre-commit, versi yang dipakai adalah versi yang dipin di konfigurasi hook, bukan versi yang terpasang di mesin pengembang. Setelah menaikkan pin, jalankan hook pada seluruh berkas sekali supaya hasilnya konsisten dengan pipeline. Tanpa langkah itu, pengembang dan CI bisa memakai versi berbeda dan saling menyalahkan temuan yang sebenarnya berasal dari perbedaan perkakas.

Untuk integrasi editor, perbarui juga ekstensi yang membungkus server bahasa Ruff. Ekstensi yang lebih tua bisa memakai jalur pemanggilan yang berbeda dan tidak mengikuti perubahan perilaku CLI di rilis ini, terutama soal prioritas variabel pewarnaan. Kalau muncul perbedaan antara hasil di editor dan hasil di terminal, periksa versi biner yang dipanggil oleh masing-masing jalur sebelum menyimpulkan ada bug.

FAQ

Apakah Ruff 0.17.4 mengubah daftar aturan stabil?

Tidak. Dua aturan baru di rilis ini masuk jalur preview, jadi daftar aturan stabil tetap sama. Kecuali Anda mengaktifkan preview, jumlah temuan pada konfigurasi yang sama seharusnya tidak berubah.

Kenapa hasil lint saya berbeda setelah upgrade padahal konfigurasinya sama?

Kemungkinan pertama, ada aturan preview yang aktif. Kemungkinan kedua, tampilan diagnostik berubah karena karakter nonprinting kini ditampilkan lebih banyak. Bandingkan keluaran terstruktur, bukan teks terminal, untuk memastikan temuannya benar-benar berbeda.

Apakah perbaikan performa ini perlu konfigurasi tambahan?

Tidak. Semua optimasi di rilis ini berjalan di dalam mesin lint dan formatter, tanpa opsi baru yang harus dinyalakan. Manfaatnya paling terasa pada repositori besar dan pada berkas dengan banyak komentar.

Di mana saya bisa membaca detail setiap perubahannya?

Catatan rilis lengkap ada di halaman rilis 0.17.4, dengan tautan ke tiap pull request. Dokumentasi aturan dan pengaturan ada di docs.astral.sh/ruff, dan daftar aturan per kelompok tersedia di halaman rules.

Rekomendasi Tools & Layanan

Mau langsung nyobain AI yang dibahas di artikel ini tanpa setup ribet? AI token plan Alibaba Cloud ngasih akses ke Qwen, DeepSeek, dan model lain lewat satu API, dan platform Qwen buat build agent sendiri. Free tier-nya cukup buat eksperimen pertama.