Next.js, Vercel, dan sharp: Pertarungan Tak Terlihat di Balik Optimasi Gambar

"Works on My Machine." - Mimpi Buruk Setiap Developer

Anda pernah mengalaminya. Aplikasi Next.js Anda berjalan sempurna di lokal. Gambar dioptimalkan dengan cepat, build berjalan lancar. Lalu Anda melakukan git push ke Vercel, dan beberapa menit kemudian, notifikasi yang ditakuti muncul: Build Failed. Seringkali, biang keladinya adalah satu kata kecil: sharp.

Dalam membangun portofolio ini, saya berhadapan langsung dengan masalah ini. Mari kita bedah mengapa `sharp` begitu istimewa dan bagaimana ekosistem Next.js beradaptasi untuk menanganinya.

Apa Sebenarnya `sharp` Itu?

sharp bukanlah library JavaScript biasa. Ini adalah "monster" pengolah gambar berkinerja tinggi yang ditulis dalam C++. Di dunia Node.js, ia dibungkus agar kita bisa memanggilnya dari JavaScript. Kemampuannya luar biasa: mengubah ukuran, mengompres, mengubah format gambar (seperti ke WebP atau AVIF) dengan kecepatan kilat.

Next.js, melalui komponen <Image>-nya, sangat bergantung pada sharp di sisi server untuk melakukan optimasi gambar secara *on-demand*. Saat Anda meminta gambar /_next/image?url=...&w=640&q=75, Next.js memanggil sharp di backend untuk menghasilkan versi gambar yang lebih kecil dan lebih efisien.

Masalahnya: Ketergantungan Asli (Native Dependencies) di Lingkungan Serverless

Di sinilah masalah dimulai. Karena sharp adalah kode C++, ia perlu dikompilasi secara spesifik untuk arsitektur sistem operasi dan CPU tempat ia akan berjalan.

Di Lokal (misalnya, Windows atau macOS): Saat Anda menjalankan npm install, npm akan mengunduh versi sharp yang sudah dikompilasi untuk sistem operasi Anda. Semuanya berjalan lancar.
Di Vercel (lingkungan serverless): Lingkungan *build* dan *runtime* Vercel menggunakan Amazon Linux (sejenis Linux). Saat Anda men-deploy, Vercel mencoba menggunakan sharp yang mungkin terinstal di lokal Anda, yang tentu saja tidak kompatibel.

Secara historis, ini menyebabkan error build yang membingungkan terkait "binary", "musl", atau arsitektur CPU. Developer seringkali harus menambahkan skrip build yang rumit untuk memaksa instalasi ulang sharp dengan arsitektur yang benar.

// package.json (Cara Lama yang Merepotkan)
"scripts": {
  "postinstall": "npm rebuild --platform=linux --arch=x64 sharp"
}

Pendekatan ini seringkali rapuh dan memperlambat proses build.

Solusi Elegan: Perubahan Arsitektur di Next.js 14+

Kabar baiknya, tim Vercel dan Next.js sangat sadar akan masalah ini. Mereka telah melakukan perubahan arsitektur yang brilian untuk menyederhanakan segalanya.

Sejak versi Next.js yang lebih baru, Anda tidak perlu lagi menginstal sharp secara manual untuk *deployment* di Vercel. Vercel secara otomatis mendeteksi bahwa Anda menggunakan Next.js Image Optimization dan menyediakan versi sharp yang sudah dioptimalkan untuk infrastruktur mereka secara *built-in*.

Bahkan, jika Anda membuat proyek Next.js baru dan men-deploy-nya, Anda akan melihat bahwa sharp mungkin tidak ada di package.json Anda sama sekali! Next.js hanya akan menginstalnya secara opsional jika mendeteksi Anda menjalankannya di lingkungan non-Vercel.

Kapan Anda Masih Perlu `sharp`?

Anda masih perlu menginstal sharp secara eksplisit jika Anda:

Menjalankan next build di lingkungan lokal Anda untuk menghasilkan situs statis penuh.
Men-deploy aplikasi Next.js Anda ke *provider* lain (selain Vercel) yang tidak menyediakan runtime sharp yang teroptimasi.
Menggunakan sharp secara langsung di kode Anda untuk pemrosesan gambar kustom.

Kesimpulan

Pertarungan dengan sharp adalah contoh sempurna dari evolusi *developer experience* di ekosistem full-stack. Apa yang dulunya menjadi sumber frustrasi besar saat deployment sekarang telah diabstraksi sepenuhnya oleh platform. Ini memungkinkan kita sebagai developer untuk fokus pada apa yang benar-benar penting—membangun fitur—dan mempercayakan kerumitan infrastruktur kepada platform seperti Vercel.

Dalam membangun portofolio ini, saya akhirnya bisa menghapus semua konfigurasi kustom terkait sharp dan membiarkan Next.js dan Vercel menangani optimasi gambar dengan "sihir" mereka. Dan terkadang, kode terbaik adalah kode yang tidak perlu kita tulis sama sekali.