Chapter sebelumnya memperlihatkan bagaimana ESLint menandai masalah kualitas kode: var, variabel tak terpakai, perbandingan longgar. Namun berkas yang lolos dari ESLint bisa tetap sulit dibaca — indentasi yang campur aduk, tanda kutip yang berganti-ganti bentuk, satu baris yang memuat setengah program. Perdebatan gaya semacam ini memakan waktu review yang seharusnya dipakai membahas logika. Prettier mengambil alih wilayah tersebut dengan pendekatan yang berbeda dari linter: alat ini membaca kode kita lalu mencetaknya ulang dari nol mengikuti gaya miliknya sendiri. Pada chapter ini kita menyiapkan konfigurasinya, memeriksa berkas yang belum rapi, lalu memperbaikinya dalam satu perintah.

Alat Pemformat yang Berpendirian #

Prettier menyebut dirinya opinionated code formatter — pemformat yang berpendirian. Cara kerjanya bukan menambal gaya lama melainkan menggantinya: kode diurai menjadi struktur, lalu dicetak ulang dari awal dengan aturan tetap yang memperhitungkan lebar baris. Dokumentasinya merangkumnya dalam satu kalimat: Prettier menghapus seluruh gaya asli dan memastikan semua kode keluar dalam gaya yang konsisten — daftar lengkap jenis berkas yang didukungnya ada di dokumentasi Prettier .

Pembagian wilayah dengan ESLint menjadi tegas: linter menilai kualitas logika — variabel tak terpakai adalah masalah apa pun gayanya — sedangkan formatter menyeragamkan tampilan. Keduanya saling melengkapi, bukan saling menggantikan. Seperti pada Chapter Linting dengan ESLint, kita memakai npx dengan versi eksplisit agar contoh di buku selalu menghasilkan keluaran yang sama:

bash 
npx --yes [email protected] --version

Output yang Dihasilkan:

text 
3.9.10

Konfigurasi dalam .prettierrc.json #

Meskipun berpendirian, Prettier tetap menerima sedikit opsi melalui berkas konfigurasi. Inilah yang kita pakai sepanjang chapter ini:

json 
{
  "printWidth": 80,
  "singleQuote": true,
  "semi": true
}

Mari kita bedah ketiganya:

  1. printWidth: 80: lebar baris maksimum yang dijaga Prettier; baris yang lebih panjang akan dipecah ke beberapa baris.
  2. singleQuote: true: string ditulis dengan kutip tunggal — konvensi yang juga dipakai seluruh contoh Course ini.
  3. semi: true: setiap pernyataan diakhiri titik koma.

Saat memformat sebuah berkas, Prettier mencari konfigurasi mulai dari folder berkas tersebut lalu naik ke atas sampai menemukannya — mekanisme yang sama dengan pencarian package.json. Alternatif tanpa berkas tambahan juga tersedia: opsi bisa diletakkan pada key "prettier" di dalam package.json. Jumlah opsinya memang sedikit secara sengaja; keputusan gaya yang lebih rinci diambil alih oleh mesin. Daftar opsi lengkap beserta nilai bawaannya terdokumentasi pada halaman opsi Prettier .

Berkas yang Berfungsi tetapi Belum Rapi #

Bahan uji kita adalah berkas yang berjalan benar namun tampilannya dibiarkan tanpa aturan:

js 
const namaToko = "Toko Budi";
const daftarBelanja = [{nama:"Beras",harga:12000,jumlah:2},{nama:"Gula",harga:16000,jumlah:1}];
function hitungTotal(daftar){let total=0;for(const item of daftar){total+=item.harga*item.jumlah}return total}
console.log(namaToko,hitungTotal(daftarBelanja))

Buktikan dulu bahwa tidak ada yang salah secara nyata:

bash 
node berkas-berantakan.mjs

Output yang Dihasilkan:

text 
Toko Budi 40000

Program mencetak total belanja dengan benar. Berkas ini bahkan lolos dari tiga aturan ESLint pada chapter sebelumnya — tidak ada var, tidak ada variabel terbuang, tidak ada == — karena masalahnya memang bukan logika. Empat persoalan tampilannya: tanda kutip ganda padahal konfigurasi kita memilih kutip tunggal, baris kedua yang melebihi batas 80 karakter, function beserta perulangan for yang dipadatkan menjadi satu baris tanpa blok, dan titik koma yang hilang pada baris terakhir.

Memeriksa tanpa Mengubah #

Flag --check memeriksa gaya tanpa menyentuh berkas sama sekali — bentuk yang aman untuk pipeline CI:

bash 
npx --yes [email protected] --check berkas-berantakan.mjs
echo "kode keluar: $?"

Output yang Dihasilkan:

text 
Checking formatting...
[warn] berkas-berantakan.mjs
[warn] Code style issues found in the above file. Run Prettier with --write to fix.
kode keluar: 1

Cara membaca keluarannya:

  1. Checking formatting...: baris pembuka yang menyatakan pemeriksaan dimulai.
  2. [warn] berkas-berantakan.mjs: berkas ini tidak sesuai gaya — satu baris per berkas bermasalah.
  3. [warn] Code style issues found in the above file. Run Prettier with --write to fix.: ringkasan sekaligus petunjuk perbaikannya.
  4. kode keluar: 1: proses berakhir dengan kode gagal — pipeline CI yang menjalankan --check akan menahan build, persis mekanisme exit code yang kita kenal dari ESLint.

Memperbaiki dengan –write #

Flag --write memformat berkas langsung di tempat. Karena flag ini mengubah berkas, kita menyalinnya dulu supaya berkas asli tetap utuh untuk dipelajari — pola yang sama dengan demo --fix pada Chapter Linting dengan ESLint:

bash 
cp berkas-berantakan.mjs salinan.mjs
npx --yes [email protected] --write salinan.mjs
cat salinan.mjs
npx --yes [email protected] --check salinan.mjs
echo "kode keluar: $?"
rm salinan.mjs

Output yang Dihasilkan:

text 
salinan.mjs
const namaToko = 'Toko Budi';
const daftarBelanja = [
  { nama: 'Beras', harga: 12000, jumlah: 2 },
  { nama: 'Gula', harga: 16000, jumlah: 1 },
];
function hitungTotal(daftar) {
  let total = 0;
  for (const item of daftar) {
    total += item.harga * item.jumlah;
  }
  return total;
}
console.log(namaToko, hitungTotal(daftarBelanja));
Checking formatting...
All matched files use Prettier code style!
kode keluar: 0

Baris pertama keluaran adalah nama berkas yang ditulis ulang — aslinya diikuti durasi pengerjaan dalam milidetik yang kita saring sesuai konvensi buku. Selebihnya adalah isi salinan.mjs hasil cat, lalu pemeriksaan ulang. Mari kita bandingkan hasilnya dengan berkas semula:

  1. Tanda kutip: "Toko Budi" menjadi 'Toko Budi' — mengikuti singleQuote: true.
  2. Baris panjang: array daftarBelanja dipecah menjadi satu objek per baris dengan indentasi dua spasi, menjaga setiap baris di bawah printWidth 80; elemen terakhir juga diberi koma buntut sesuai perilaku bawaan Prettier.
  3. Blok yang dipaksakan: function hitungTotal dan perulangan for kini masing-masing berdiri di blok kurung kurawal sendiri — satu baris padat menjadi tujuh baris yang mudah dipindai.
  4. Titik koma: seluruh pernyataan ditutup ; sesuai semi: true.
  5. All matched files use Prettier code style! dan kode keluar: 0: pemeriksaan ulang --check kini hijau — bukti bahwa --write dan --check menilai dengan standar yang sama.

Perintah rm di akhir menghapus salinan agar demonstrasi bisa diulang dengan hasil identik. Perhatikan pula bahwa tidak ada satu pun perubahan perilaku: program yang sama, keluaran yang sama, hanya cara menulisnya yang diseragamkan.

Prettier di Editor dan Pipeline #

Dua titik pemakaian lain melengkapi siklusnya. Di editor, ekstensi Prettier untuk VS Code dan editor populer lainnya dapat menjalankan format otomatis setiap kali berkas disimpan — kode rapi sudah terbentuk sebelum sampai ke rekan tim. Di pipeline, --check menjadi gerbang seperti yang kita lihat: exit code 1 menahan penggabungan sampai berkas dirapikan. Pada proyek nyata, pemeriksaan biasanya menarget seluruh proyek (npx prettier --check .) dengan pengecualian didaftarkan pada berkas .prettierignore — contoh di buku ini menyebut berkasnya satu per satu supaya fokus; daftar flag lengkapnya ada di dokumentasi CLI Prettier .

Prettier sendiri hanya peduli tampilan; alat ini bahkan tidak mengerti apakah sebuah variabel terpakai. Pertanyaannya kini: bagaimana caranya menempatkan dua alat — ESLint untuk logika, Prettier untuk tampilan — dalam satu proyek tanpa keduanya saling mengganggu? Chapter Konsistensi Gaya Kode menyusun alur kerja lengkapnya.