CSS Unminifier vs Prettier: Kapan Menggunakan Masing-masing

Terakhir ditinjau 2026-05-05. CSS Unminifier dan Prettier keduanya adalah formatter, tetapi mereka menyelesaikan masalah yang berbeda. CSS Unminifier membaca CSS produksi yang diminifikasi dan menyebarkannya kembali sehingga setiap selektor dan deklarasi berada di barisnya sendiri - ideal untuk men-debug stylesheet yang dikirim yang sumbernya tidak Anda miliki. Prettier memformat sumber CSS yang akan Anda commit, menerapkan aturan .prettierrc tim Anda sehingga diff setiap developer tetap bersih. Pilih yang tepat dalam 30 detik dengan tabel di bawah, dan baca sisa panduan ini jika Anda ingin tahu mengapa pilihan yang salah menghasilkan output yang tidak konsisten. Coba CSS Unminifier bersama panduan ini untuk paruh baca-CSS-terkirim.

Apa yang sebenarnya dilakukan CSS Unminifier (dan apa yang tidak bisa dilakukan)

CSS Unminifier di situs ini membaca string CSS yang diminifikasi (jenis yang diproduksi oleh cssnano, csso, clean-css, atau build produksi apa pun yang menjalankan CSS melalui minifier) dan memancarkan aturan yang sama dengan indentasi yang tepat, line break, dan satu deklarasi per baris. Alat ini berjalan sepenuhnya di browser Anda - halaman dibangun di sekitar parsing in-browser dari konten textarea, tanpa unggahan, tanpa akun. Salinan verbatim pada halaman alat berbunyi "stylesheet produksi yang dibangun dan Anda perlu membacanya atau mengeditnya"; itulah kasus penggunaan kanonik.

Apa yang unminifikasi pulihkan:

• Whitespace antara selektor, deklarasi, dan blok aturan. Output dapat dibaca baris demi baris lagi.
• Line breaks setelah setiap deklarasi. Setiap property: value; duduk di barisnya sendiri.
• Indentasi di dalam blok aturan. Setiap deklarasi diindentasi di bawah selektornya.

Apa yang unminifikasi TIDAK dan TIDAK DAPAT pulihkan:

• Komentar. Sebagian besar minifier produksi menghapus komentar sebelum output (cssnano default, csso default). Setelah dihapus, komentar asli hilang - unminifier tidak memiliki apa pun untuk diletakkan kembali.
• Gaya format asli. Unminifier menghasilkan output kanonik "satu deklarasi per baris". Jika sumber Anda menggunakan konvensi berbeda (daftar selektor multi-baris yang diindentasi, deklarasi dikelompokkan berdasarkan kategori visual, prefiks vendor disejajarkan), konvensi itu tidak ada dalam file yang diminifikasi dan tidak dapat direkonstruksi.
• Nama variabel dari CSS-in-JS atau CSS Modules. Jika pipeline build menjalankan CSS Modules atau alat CSS-in-JS yang meng-hash nama kelas (.SubmitButton_xY7g3, .modal-_2hqf), nama kelas semantik asli hilang. Unminifier menampilkan nama yang di-hash karena itulah yang ada di file.
• Source maps. Jika build produksi tidak mempertahankan entri sourceMap, unminifier tidak dapat memulihkan path file asli atau nomor baris. Itu hanya memformat apa yang ada di textarea.

Jika tujuan Anda adalah "baca CSS yang diminifikasi ini untuk menemukan aturan tertentu", unminifier memberikan tepat itu. Jika tujuan Anda adalah "memulihkan sumber asli", itu adalah tugas yang berbeda (dan biasanya tidak mungkin).

Prettier (dan auto-format IDE Anda) melakukan pekerjaan yang berbeda - inilah garisnya

Prettier adalah formatter sumber yang berpendapat. Inputnya adalah sumber CSS yang Anda tulis (atau akan ditulis), dan outputnya adalah CSS yang sama yang ditulis ulang sesuai dengan file konfigurasi (biasanya .prettierrc atau prettier.config.js di root repo). Prettier dirancang untuk dijalankan pada setiap simpan, setiap commit, di hook pre-merge di CI - formatter yang menegakkan satu gaya di seluruh tim. Sebagian besar ekstensi editor (VS Code "Prettier - Code formatter", JetBrains "Prettier", Sublime "JsPrettier") menghubungkannya ke aksi format-saat-simpan.

Dua hal yang membuat Prettier berbeda dari unminifier:

1. Prettier dikendalikan konfigurasi. Semicolon trailing, lebar indentasi (2 vs 4), penanganan whitespace trailing, panjang baris, kutip tunggal vs kutip ganda dalam url() - setiap tim memilih kombinasi yang berbeda, mengkodifikasikannya dalam .prettierrc, dan Prettier menegakkan kombinasi itu pada setiap file. Unminifier tidak memiliki konfigurasi; selalu menghasilkan output kanonik yang sama "satu aturan per baris".
2. Prettier mengharapkan input yang dapat dibaca. Prettier tidak dibangun untuk menangani stylesheet yang diminifikasi satu baris. Itu dapat berjalan pada CSS yang diminifikasi dan akan menghasilkan sesuatu yang diformat, tetapi output menggunakan aturan panjang baris Prettier sendiri (default 80 karakter), konvensi pengelompokan Prettier sendiri, dan gaya kutip Prettier - yang biasanya TIDAK cocok dengan file yang akan diproduksi unminifier. Kasus terburuk (jarang): Prettier mungkin menolak memformat CSS yang dianggap rusak (kurung tutup ekstra, pseudo-kelas tidak valid) di mana unminifier hanya memancarkan byte apa pun yang diterimanya.

Model mental paling sederhana: CSS Unminifier adalah penampil; Prettier adalah penulis. Penampil adalah untuk melihat file yang tidak Anda miliki. Penulis adalah untuk meng-commit file yang Anda miliki.

Baca CSS terkirim dengan cepat: kapan CSS Unminifier adalah jawaban tercepat

Tiga alur kerja adalah teritori kanonik CSS Unminifier. Dalam ketiganya, input adalah stylesheet produksi yang diminifikasi dan tujuannya adalah membacanya sekali, bukan meng-commit apa pun:

• Men-debug bug spesifisitas di produksi. Buka DevTools, lihat aturan yang menang, salin selektor lengkapnya, tempel CSS yang diminifikasi ke unminifier, cari selektor. Output yang di-unminify membuat mudah memindai ke atas cascade dan melihat aturan lain mana yang mungkin berperan. Lebih cepat daripada menggulir melalui baris 200 karakter.
• Memeriksa stylesheet pihak ketiga. Jika perpustakaan vendor (Bootstrap, CSS yang dikompilasi Tailwind, CSS widget tertanam) mengganggu gaya Anda dan Anda tidak memiliki sumber, tempel file yang diminifikasi ke unminifier dan baca aturan secara langsung. Sering kali Anda menemukan aturan yang menyinggung dalam 30 detik.
• Menyerahkan salinan bersih ke rekan satu tim. Laporan bug dari QA tiba dengan lampiran CSS yang diminifikasi. Tempel, unminify, bagikan output yang diformat di komentar pelacak bug sehingga pembaca berikutnya tidak harus menggulir secara horizontal.

Dalam ketiganya, unminifier menang karena ada di browser, tidak memerlukan instalasi, dan menghasilkan output yang dapat Anda cari dengan Ctrl-F. Menjalankan Prettier pada input yang sama memerlukan baik instalasi lokal (npx prettier file.css menulis ke disk) atau menempelkan ke playground Prettier - keduanya lebih lambat daripada alat satu-tempel yang berjalan di sisi klien.

Menulis sumber CSS: kapan Prettier adalah pilihan yang tepat

Tiga alur kerja milik Prettier. Dalam ketiganya, input adalah sumber CSS yang ditulis developer dan tujuannya adalah memformatnya untuk commit:

• Format-saat-simpan di editor. VS Code dan JetBrains keduanya menghubungkan Prettier ke aksi format ketika .prettierrc hadir di repo. Setiap kali developer menyimpan file CSS, Prettier menulis ulang sesuai dengan aturan tim. Unminifier tidak dapat dihubungkan ke format-saat-simpan (tidak memiliki CLI; itu adalah halaman web) dan akan mengabaikan aturan .prettierrc bagaimanapun.
• Hook pre-commit di git. Alat seperti lint-staged + husky menjalankan Prettier pada setiap file CSS yang di-stage sebelum commit mendarat. Diff selalu diformat Prettier. Pengulas hanya melihat perubahan logis, bukan drift whitespace. Unminifier tidak memiliki integrasi hook.
• Pemeriksaan format CI. Langkah CI menjalankan prettier --check src/**/*.css. Jika ada file yang tidak cocok dengan aturan Prettier, build gagal. Memaksa format lokal setiap developer untuk cocok dengan aturan tim. Unminifier tidak dapat menegakkan pemeriksaan: outputnya adalah kanonik-baris-per-aturan, yang berbeda dari .prettierrc tim mana pun.

Jika Anda meng-commit CSS, jalankan Prettier (via editor Anda, hook pre-commit Anda, atau CLI). Jika Anda membaca CSS yang tidak Anda miliki, tempel ke CSS Unminifier. Melakukan kebalikan - menjalankan Prettier pada stylesheet yang diminifikasi untuk "membacanya" - menghasilkan output yang tidak cocok dengan konvensi sumber tim Anda DAN tidak cocok dengan konvensi pembacaan CSS standar mana pun. Itu adalah yang terburuk dari kedua dunia.

Apa yang tidak dapat dipulihkan oleh alat mana pun setelah build tree-shaking

Pipeline CSS produksi melakukan lebih dari sekadar minify. Sebagian besar rantai build modern menjalankan urutan transformasi yang menghapus informasi, dan setelah informasi hilang, tidak ada formatter (unminifier atau Prettier) yang dapat memasangnya kembali. Mengetahui apa yang dihapus membantu menetapkan harapan untuk seperti apa output "di-unminify" Anda akan terlihat:

• Tree-shaking menghapus aturan yang tidak digunakan. Alat seperti PurgeCSS, UnCSS, dan mesin JIT Tailwind mengkompilasi sumber terhadap HTML/JSX aplikasi dan memancarkan hanya aturan yang cocok dengan nama kelas yang digunakan. Stylesheet output adalah SUBSET dari sumber, dalam urutan yang berbeda. Unminifier dapat memformat subset itu tetapi tidak dapat memberi tahu Anda aturan mana yang dihapus.
• Mangling nama variabel pada CSS-in-JS atau CSS Modules. CSS Modules menulis ulang .button menjadi .Button_button_2hQF (atau lebih pendek); perpustakaan CSS-in-JS (styled-components, emotion) menulis ulang .MyButton menjadi .css-1n3v7p9. Nama yang di-hash bersifat deterministik tetapi buram. Unminifier menampilkan nama yang di-hash karena itulah yang ada di file.
• Komentar dihapus pra-build. Sebagian besar minifier menghapus komentar /* ... */ secara default. Beberapa mempertahankan komentar spanduk /*! preserve */ (header lisensi); sisanya hilang sebelum file meninggalkan pipeline build. Baik unminifier maupun Prettier tidak memulihkannya.
• Source maps terlepas. Jika build memancarkan file style.css.map tetapi Anda hanya memiliki style.css, Anda tidak dapat kembali ke nomor baris asli. Unminifier memformat apa yang Anda miliki; Prettier melakukan hal yang sama. Keduanya bergantung pada Anda juga mengambil source map jika Anda memerlukan navigasi sumber asli.
• Pengelipsan prefiks vendor. Autoprefixer sering memancarkan satu aturan dengan beberapa varian prefiks (-webkit-, -moz-, -ms-, standar). Setelah minifikasi, urutan prefiks dapat dikocok untuk output terpendek. Unminifier menunjukkan urutan akhir itu; output Autoprefixer asli memiliki urutan berbeda di sumber.

Jika tujuan Anda adalah "rekonstruksi penuh sumber", jawabannya adalah: buka repositori git build atau ambil source map yang cocok. Baik CSS Unminifier maupun Prettier tidak dapat merekonstruksi apa yang dihapus pipeline build.

Pasangkan unminifier dengan sisa toolset CSS

Jika file yang Anda baca berasal dari build produksi Anda sendiri dan Anda akan RE-minify setelah membaca (jalur round-trip "lihat, edit, kirim"), pasangkan unminifier dengan CSS Minifier di situs ini untuk perjalanan kembali. Minifier membalikkan langkah format (menjatuhkan whitespace dan line breaks kembali) dan menghasilkan file satu baris yang dapat di-deploy. Kedua alat bersama-sama mencakup kedua arah loop produksi-ke-sumber-ke-produksi.

Jika Anda tidak yakin apakah file yang Anda miliki adalah output "minifier" (whitespace dihapus) atau output "uglifier" / tree-shaker (variabel juga diganti namanya), panduan CSS minifier vs uglifier vs tree-shaking menjelaskan cara membedakannya dalam satu paragraf. Jika Anda memilih minifier vs kompresor (gzip/brotli), panduan minifier vs kompresor mencakup kebingungan yang berdekatan itu. Jika Anda menjalankan deployment Cloud Run atau Lambda dan khawatir tentang byte CSS cold-start, panduan cara minify CSS/JS untuk cold-start Cloud Run mencakup kasus yang dikendalikan anggaran.

Pertanyaan yang sering diajukan

Apakah output yang di-unminify sama dengan sumber CSS asli?

Hampir tidak pernah. Unminifier membalikkan langkah whitespace tetapi tidak dapat membalikkan penghapusan komentar, mangling variabel, tree-shaking, atau pengurutan ulang prefiks vendor. Perlakukan output sebagai "CSS produksi yang dapat dibaca", bukan "sumber asli". Jika Anda memerlukan sumber asli, ambil repositori git build atau source map.

Mengapa nama variabel saya berbeda setelah saya unminify?

Mereka tidak berbeda - mereka adalah nama yang sama yang ditulis pipeline build ke file. Rantai build modern menulis ulang nama kelas melalui CSS Modules atau hashing CSS-in-JS untuk isolasi cakupan, sehingga stylesheet produksi berisi .Button_xY7g3 alih-alih .Button. Unminifier menampilkan apa yang ada di file; tidak dapat un-hash nama karena pemetaan build tidak ada.

Bisakah saya menjalankan Prettier pada output yang di-unminify?

Ya, dan hasilnya akan diformat Prettier (cocok dengan set aturan .prettierrc apa pun yang Anda arahkan Prettier). Tetapi unminifier sudah menghasilkan output kanonik "satu deklarasi per baris" yang bagus untuk dibaca; menjalankan Prettier di atasnya hanya mengubah gaya format agar cocok dengan aturan tim Anda. Sebagian besar pembaca tidak repot-repot. Jika Anda akan meng-commit file sebagai sumber, maka ya - jalankan Prettier berikutnya, karena Prettier cocok dengan format commit tim Anda.

Apakah CSS Unminifier akan menangani hash kelas CSS Modules?

Itu akan memformatnya dengan baik (hash adalah nama kelas CSS yang valid). Apa yang tidak dapat dilakukannya adalah memetakan kembali ke nama yang dapat dibaca manusia dari sumber Anda. Jika Anda memiliki source map build, DevTools Anda dapat menampilkan nama manusia dengan memetakan kembali melalui source map; unminifier sendiri tidak dapat.

Adakah cara untuk memulihkan komentar setelah build?

Hanya jika minifier build dikonfigurasi untuk mempertahankannya (sebagian besar tidak secara default). Konfigurasikan build Anda untuk mempertahankan komentar spanduk /*! ... */ melalui opsi preserve atau comments: 'some' minifier. Setelah dihapus, komentar tidak dapat dipulihkan melalui pemformatan.

Terkait

• CSS Unminifier - alat yang ditulis panduan ini untuk menemani. Menempelkan CSS yang diminifikasi, mengembalikan CSS yang diformat, berjalan sepenuhnya di browser Anda.
• CSS Minifier - alat arah berlawanan untuk re-minifikasi setelah pembacaan. Pengaturan yang sama di browser, tanpa akun.
• CSS minifier vs kompresor - panduan pendamping pada arah maju. Mengklarifikasi terminologi minifier-vs-gzip yang sering dicampur developer.
• CSS minifier vs uglifier vs tree-shaking - panduan pendamping pada urutan pipeline build. Menjelaskan apa yang sebenarnya dilakukan setiap transformasi dan kapan menerapkan masing-masing.
• Cara minify CSS/JS untuk cold-start Cloud Run - panduan khusus deployment untuk anggaran cold-start.