Yarn Cache Clean: Cara Membersihkan Cache Yarn (v1, Berry)

Jawaban cepat: Pencarian orang yarn clear cache dan bersihkan cache yarn, tetapi CLI Yarn menggunakan yarn cache clean. Periksa versi Yarn yang Anda gunakan:

yarn --version

Jalankan yarn config get enableGlobalCache untuk melihat pengaturan yang berlaku. Flag Berry: yarn cache clean --all menghapus scope cache aktif plus mirror jika diaktifkan; tidak selalu menghapus semua cache global dan proyek di mesin. yarn cache clean --mirror menghapus mirror terpisah hanya jika ada, dan mungkin tidak melakukan apa-apa jika tidak. Periksa path: Klasik yarn cache dir menampilkan folder cache ber-versi; sebuah yarn cache clean menghapus root cache induknya. Berry yarn config get cacheFolder.

You run yarn install, dan dependensi yang baru Anda perbarui masih merujuk ke build lama. Atau laptop Anda menginstal dengan baik, tetapi CI tiba-tiba gagal setelah perubahan lockfile yang tidak berbahaya. Perilaku cache bergantung pada Yarn Classic versus Yarn Berry, cakupan cache, dan apakah masalah sebenarnya ada pada lockfile atau desain cache pipeline, bukan hanya tarball yang disimpan. Untuk kebersihan dependensi CI yang lebih luas, lihat Integrasi CI/CD Capacitor OTA updates.

Table of Contents

• Build Anda Rusak dan Cache Yarn Mungkin Penyebabnya
• Kapan dan Mengapa Harus Clear Yarn Cache
  • Gejala yang menunjukkan adanya masalah cache
  • Kapan sebaiknya tidak menggunakan Yarn clear cache
• Yarn cache clean di Yarn Classic v1
  • Apa yang benar-benar dihapus oleh perintah ini
  • Cara memverifikasi lokasi cache
• Manajemen Cache Modern di Yarn Berry v2+
  • Berry mengubah model cache
  • Perintah yang penting di Berry
• Best Practices Yarn Cache untuk CI/CD dan Docker
  • Mengapa menghapus cache di pipeline sering kali merupakan langkah yang salah
  • Pendekatan CI dan Docker yang lebih baik
• Troubleshooting Yarn cache clean
  • Saat clean yang ditargetkan masih menyisakan package lama
  • Masalah permission dan environment yang mirip error cache
• FAQ Seputar Cara Membersihkan Yarn Cache
  • Apa perintah yang benar untuk yarn clear cache?
  • Bagaimana cara menjalankan yarn cache clean di Yarn Classic vs Yarn Berry?
  • Apakah aman untuk membersihkan cache Yarn?
  • Kapan sebaiknya menghindari pembersihan cache Yarn di CI atau Docker?
  • Bagaimana cara memverifikasi di mana Yarn menyimpan cache?
  • Mengapa paket lama tetap ada setelah yarn cache clean?

Build Anda Rusak dan Cache Yarn Mungkin Penyebabnya

Pola yang familiar terlihat seperti ini. Anda menaikkan versi package, menarik perubahan terbaru, lalu menjalankan install lagi. Perintah selesai, tetapi aplikasi masih berperilaku seolah dependensi lama masih ada. Lalu seseorang menyarankan untuk membersihkan cache, dan sekarang Anda bertanya-tanya apakah itu solusi nyata atau sekadar takhayul.

Ini bisa jadi solusi nyata. Tapi bisa juga hanya pengalih perhatian.

Masalah cache biasanya muncul dengan beberapa cara yang bisa diprediksi. Package lokal tidak mau refresh. CI menarik sesuatu yang tidak diharapkan. Branch baru berperilaku berbeda dari branch utama meskipun lockfile mengatakan semuanya harus cocok. Jika Anda sudah mengejar ketidakstabilan pipeline yang lebih luas, membantu untuk memasangkan debugging cache dengan review build yang lebih sistematis, seperti panduan ini tentang memperbaiki kegagalan build di pipeline CI/CD Capacitor.

Aturan praktis: Anggap Yarn clear cache sebagai alat diagnostik, bukan ritual pemeliharaan.

Bagian yang rumit adalah Yarn telah mengubah model cache-nya seiring waktu. Di proyek lama, cache dibagikan secara global. Di proyek baru, pembersihan cache bisa bersifat lokal untuk proyek, global, atau keduanya, tergantung pada flag perintah. Jadi ketika rekan tim mengatakan “cukup bersihkan cache Yarn,” pertanyaan pertama seharusnya adalah: Yarn yang mana?

Itulah mengapa perbaikan cache yang baik dimulai dengan konteks. Mesin lokal atau CI runner. Yarn v1 atau Berry. Cache bersama atau cache proyek. Setelah Anda tahu itu, perintah menjadi presisi, bukan sekadar harapan.

Kapan dan Mengapa Harus Clear Yarn Cache

Membersihkan cache Yarn masuk akal jika Anda memiliki mode kegagalan spesifik. Ini paling berguna saat Anda perlu menghapus artefak paket yang usang, memulihkan dari status download yang rusak, atau sengaja menghapus paket yang tersimpan agar Yarn membangun ulang dari awal.

Gejala yang menunjukkan adanya masalah cache

Beberapa kasus adalah kandidat kuat untuk cache:

• Sebuah dependensi menolak untuk diperbarui: Anda telah mengubah versi atau membangun ulang paket lokal, tetapi instalasi masih menarik artefak yang lebih lama.
• Instalasi gagal dengan cara yang terasa stateful: Satu mesin berfungsi, yang lain tidak, dan menjalankan ulang perintah yang sama terus mereproduksi hasil buruk yang sama.
• Anda perlu merebut kembali ruang disk lokal: Ini lebih penting di mesin developer daripada di lingkungan CI yang berumur pendek.

Situasi lain hanya terlihat seperti masalah cache. Jika lockfile Anda berubah secara tidak terduga, jika setup workspace tidak konsisten, atau jika build Docker membatalkan layer yang salah, membersihkan cache tidak akan mengatasi akar masalahnya. Tim yang bekerja pada build aplikasi sering mengalami ini sambil mengatur native tooling, dependensi JavaScript, dan pembaruan plugin. Dalam konteks tersebut, ringkasan praktis ini tentang mengelola dependensi dalam proyek Capacitor layak disimpan di dekat Anda.

Jika tujuan Anda adalah pembersihan mesin yang lebih luas, bukan troubleshooting paket, panduan tingkat sistem juga bisa membantu. Developer Mac yang ingin membersihkan cache aplikasi untuk pengguna Mac sering menemukan bahwa package manager hanyalah satu bagian dari gambaran penyimpanan.

Kapan sebaiknya tidak menggunakan Yarn clear cache

Jangan gunakan Yarn clear cache sebagai respons pertama untuk setiap masalah instalasi.

Gunakan hanya jika ada bukti kondisi paket yang usang atau rusak. Lewati jika masalahnya lebih mungkin disebabkan oleh:

Jika instalasi salah karena environment yang salah, menghapus cache hanya akan membuat instalasi salah berikutnya jadi lebih lambat.

Perbedaan ini menghemat waktu. Banyak waktu debugging terbuang karena menganggap cache sebagai tombol reset ajaib.

Yarn cache clean di Yarn Classic v1

Yarn Classic berperilaku seperti yang masih diasumsikan banyak developer untuk semua versi Yarn. Ia memakai cache global di direktori user, dan yarn cache clean membersihkan cache bersama tersebut. Dokumentasi resmi Yarn Classic sendiri menjelaskannya demikian, dan mencatat bahwa cache akan terisi ulang pada yarn atau yarn install jalankan di direktori user model yang didokumentasikan di dokumentasi cache Yarn Classic CLI.

Apa yang sebenarnya dihapus oleh perintah ini

Untuk Yarn v1, perintah pembersihan defaultnya sederhana:

yarn cache clean

Perintah tersebut menghapus cache bersama, bukan hanya proyek saat ini. Jika Anda bekerja di beberapa repositori pada mesin yang sama, hal ini penting. Instalasi berikutnya di salah satu repositori mungkin perlu mengambil paket lagi.

Desain cache bersama ini adalah salah satu alasan mengapa Yarn v1 dapat menghasilkan perilaku lintas proyek yang membingungkan. Artefak usang di cache global dapat bertahan cukup lama untuk memengaruhi repositori yang berbeda, terutama ketika pengembangan paket lokal terlibat.

Urutan praktis untuk Yarn Classic biasanya seperti ini:

1. Jalankan perintah clean terlebih dahulu: yarn cache clean
2. Hapus artefak instalasi lokal jika diperlukan: node_modules sering kali menjadi langkah berikutnya jika state masih terlihat tidak konsisten.
3. Instal ulang dari awal: Jalankan yarn install lagi dan pastikan dependency graph ter-resolve sesuai harapan.

Cara memverifikasi lokasi cache

Saat Anda ingin memeriksa atau menghapus direktori cache secara langsung, Yarn Classic memberikan path-nya:

yarn cache dir

Ini berguna saat perintah CLI sepertinya tidak memperbaiki masalah, atau saat Anda perlu memastikan akun pengguna mana yang memiliki direktori cache di lingkungan shared atau containerized.

Di Yarn Classic 1.22, yarn cache dir menunjuk ke folder berversi di bawah root cache (misalnya v6 di bawah default macOS ~/Library/Caches/Yarn tree). Perintah yarn cache clean tanpa nama paket akan menghapus root cache induknya, bukan hanya subdirektori berversi. Jika Anda mengatur cache-folder ke path yang juga menyimpan file non-Yarn, pembersihan penuh dapat menghapusnya. Gunakan root cache khusus, dan periksa parent dari yarn cache dir sebelum Anda menghapus cache.

Jika Anda bekerja dengan toolchain lama dan ingin menjaga setup lokal tetap prediktabel, panduan tentang cara instal Capacitor CLI langkah demi langkah cocok dipadukan dengan reset dependency yang bersih.

Inspeksi cache manual sering kali lebih berguna daripada perintah cleanup buta kedua.

Untuk proyek v1, mental model-nya sederhana. Satu cache bersama, satu perintah cleanup menyeluruh, dan install berikutnya mengisi ulang apa yang Anda hapus.

Manajemen Cache Modern di Yarn Berry v2+

Yarn Berry mengubah cara pandang. Jika Anda terbiasa dengan Yarn v1, penyesuaian terbesarnya adalah pembersihan cache bukan lagi sekadar "hapus global store lalu coba lagi." Berry mendukung kontrol yang lebih presisi, yang berguna setelah Anda tahu apa targetnya.

Berry mengubah model cache

Di Yarn modern, perilaku cache jauh lebih erat terkait dengan proyek itu sendiri. Hal ini sejalan dengan pendekatan Berry yang lebih luas pada kontrol level proyek, Plug’n’Play, dan workflow di mana dependency bisa berada berdampingan dengan repo, bukan dalam satu model cache untuk seluruh mesin.

Itulah mengapa saran lama bisa menyesatkan. Rekan tim yang belajar Yarn di v1 mungkin mengira satu perintah bisa menghapus semuanya secara global. Di Berry, Anda perlu berpikir soal cakupan.

Jika Anda berurusan dengan output build yang berbeda di pipeline mobile dan web, pola pikir scope yang sama juga berlaku di luar package management. Perbandingan jenis build adalah pengingat berguna bahwa asumsi soal environment cenderung terbawa ke proses debugging.

Berikut penjelasan visual singkat sebelum masuk ke detail perintahnya:

Perintah yang penting di Berry

Yarn modern mendokumentasikan yarn cache clean di referensi perintah Yarn cache clean saat ini. Scope bergantung pada nilai efektif enableGlobalCache dari yarn config get enableGlobalCache:

• Dengan enableGlobalCache: true (default Yarn 4+), yarn cache clean menghapus cache global bersama yang digunakan langsung oleh Yarn.
• Dengan enableGlobalCache: false (default Yarn 2 dan 3), yarn cache clean menghapus direktori cache aktif (default ./.yarn/cache, sering kali di-commit untuk zero-install; custom cacheFolder dapat menunjuk ke lokasi lain dan juga dihapus).
• yarn cache clean --all menghapus scope cache aktif dan mirror terpisah jika diaktifkan. Dengan enableMirror: false, cache global proyek lain dapat tetap ada. Dengan enableGlobalCache: true, proyek lokal lama .yarn/cache tetap ada.
• yarn cache clean --mirror membersihkan cache mirror terpisah hanya jika ada. Jika Yarn sudah memakai cache global secara langsung, --mirror mungkin tidak menghapus apa pun.

Gunakan --all untuk pembersihan terluas yang ditawarkan Berry untuk konfigurasi saat ini, lalu verifikasi dengan yarn config get cacheFolder dan periksa path tersebut jika masih ada file lama. Gunakan --mirror hanya setelah Anda mengonfirmasi bahwa proyek menggunakan mirror.

Titik keputusan: Di Berry, memilih scope yang salah adalah salah satu alasan utama mengapa pembersihan cache tampak "tidak melakukan apa-apa."

Itulah perbedaan praktisnya. Yarn Classic bersifat luas secara default. Berry bersifat eksplisit oleh desain.

Best Practices Yarn Cache untuk CI/CD dan Docker

Dalam CI/CD, menghapus cache Yarn secara membabi buta biasanya adalah kesalahan. Terasa aman karena menghapus state, tapi sering kali justru menghapus state yang dibutuhkan pipeline Anda untuk kecepatan dan konsistensi.

Pertanyaan yang lebih berguna adalah: apa sebenarnya yang Anda cache, dan apa sebenarnya yang Anda restore?

Mengapa menghapus cache di pipeline sering kali merupakan langkah yang salah

Diskusi CircleCI merekam pola kegagalan yang sering dialami banyak tim di proyek nyata. Install yang lambat tidak teratasi dengan pembersihan cache karena bottleneck-nya bukan arsip package yang basi. Masalahnya ada pada perilaku fetch dan link, ketidakcocokan cache-directory, dan hilangnya node_modules path dalam set cache, seperti yang dijelaskan dalam thread caching Yarn di CircleCI tersebut.

Hal ini penting karena sistem CI sering menyembunyikan penyebab sebenarnya di balik satu gejala samar: “install lambat” atau “step dependency tidak stabil.” Developer kemudian menghapus cache, rerun, dan tidak mendapat peningkatan berarti.

Kesalahan umum pada pipeline meliputi:

• Caching direktori yang salah: Step restore selesai, tetapi Yarn tidak menggunakan lokasi hasil restore.
• Mengabaikan path workspace: Dependensi root mungkin dipulihkan sementara kerja instalasi workspace masih perlu relinked.
• Membangun lapisan Docker dengan urutan yang salah: Salinan code sumber membatalkan lapisan dependensi, sehingga instalasi paket dijalankan ulang setiap kali.

Di CI, cache miss akibat konfigurasi buruk terlihat sangat mirip dengan cache yang rusak.

Jika Anda membangun aplikasi mobile di lingkungan otomatis, di sinilah tooling rilis mulai berperan. Tim sering menggabungkan GitHub Actions atau CircleCI dengan sistem distribusi dan pembaruan. Salah satu opsi dalam alur kerja yang lebih luas tersebut adalah Pengaturan CI/CD Capgo untuk aplikasi Capacitor, dan menghadirkan Capgo cloud build untuk remote native builds yang berjalan berdampingan dengan strategi package-manager dan build-cache Anda.

Pendekatan CI dan Docker yang lebih baik

Gunakan cache invalidation secara sengaja, bukan berdasarkan emosi.

Untuk CI, pola yang andal terlihat seperti ini:

1. Cache berdasarkan status dependensi: Hubungkan cache keys dengan yarn.lock dan file konfigurasi Yarn yang relevan.
2. Pulihkan sebelum install: Pastikan path yang dipulihkan sesuai dengan path yang akan digunakan Yarn di lingkungan tersebut.
3. Install secara konsisten: Di setup immutable, gunakan mode install yang menegakkan kebenaran lockfile.
4. Invalidate pada perubahan nyata: Perubahan versi Yarn, pembaruan lockfile, atau perubahan jalur cache adalah alasan yang baik untuk membangun ulang cache.

Untuk Docker, prinsipnya serupa:

• Salin manifest dependensi terlebih dahulu: Jaga agar layer instal dependensi terpisah dari sumber aplikasi jika memungkinkan.
• Hindari pembersihan yang tidak perlu dalam build image: Menghapus cache dalam build yang sama sering kali menghilangkan reuse layer yang berguna.
• Tentukan kepemilikan user secara eksplisit: Direktori cache yang dibuat oleh root dapat menyebabkan kegagalan instalasi bagi user runtime non-root.

Tabel keputusan singkat ini dapat membantu:

Gunakan Yarn clear cache di CI hanya jika Anda sudah memastikan konten cache yang usang adalah masalah sebenarnya. Sebagian besar waktu, solusinya adalah desain cache yang lebih baik.

Troubleshooting Yarn cache clean

Bug cache yang paling menyebalkan adalah yang tetap ada setelah cache clean. Anda menjalankan pembersihan target, menginstal ulang, dan Yarn masih menarik paket lama. Pada titik itu, godaan untuk mengasumsikan registry salah atau lockfile 'terhantui' sangat kuat.

Sebuah masalah historis yang terdokumentasi di Yarn menunjukkan mengapa hal itu terjadi. Developer melaporkan bahwa yarn cache clean <package-name> bisa meninggalkan salinan lama di cache/.tmp, yang berarti instalasi terus menggunakan versi yang sudah usang sampai direktori sementara itu dihapus atau pembersihan penuh dijalankan, seperti yang dibahas di isu Yarn tentang artefak cache yang usang di .tmp.

Saat clean yang ditargetkan masih menyisakan package lama

Pelajarannya sederhana. Pembersihan parsial tidak selalu cukup.

Jika Anda mencurigai versi yang usang daripada kerusakan luas, gunakan urutan ini:

• Mulai dengan pemeriksaan yang jelas: Pastikan Anda sedang mendalami versi dan sumber paket yang diharapkan.
• Jangan terlalu percaya pada pembersihan spesifik paket: Pembersihan yang ditargetkan bisa meninggalkan artefak sementara.
• Eskalasi ke penghapusan cache penuh: Di Classic, jalankan yarn cache clean tanpa nama package, lalu yarn install. Di Berry, gunakan yarn cache clean --all untuk cakupan terluas yang diizinkan konfigurasi Anda.
• Periksa jalur cache temp secara manual: Di setup lama, cache/.tmp bisa jadi bagian yang hilang.

Ketika sebuah package terus teresolve ke artifact lama, file cache temp sering jadi tempat pertama yang saya periksa setelah clean target gagal.

Masalah permission dan environment yang mirip error cache

Tidak semua “cache error” adalah masalah konten cache.

Di Docker, sistem Linux multi-user, atau CI runners, Anda bisa menemui kegagalan izin karena direktori cache dimiliki oleh user yang berbeda dari proses yang menjalankan Yarn. Dalam kasus itu, membersihkan cache tidak akan membantu sampai masalah kepemilikan diperbaiki. Langkah praktisnya adalah menjalankan Yarn sebagai user yang benar, atau memperbaiki kepemilikan direktori sebelum menginstal ulang.

Masalah seperti ini sering muncul seperti cache yang sudah basi karena instalasi gagal secara tidak konsisten di berbagai lingkungan. Solusinya bersifat operasional, bukan terkait paket.

FAQ Seputar Cara Membersihkan Yarn Cache

Apa perintah yang benar untuk yarn clear cache?

Yarn tidak menyediakan yarn clear cache subcommand. Perintah yang terdokumentasi adalah yarn cache clean. Pada Yarn Classic v1, perintah ini membersihkan cache global di direktori pengguna Anda. Pada Yarn Berry v2 dan seterusnya, cakupan bergantung pada flag dan pada enableGlobalCache dari yarn config get enableGlobalCache.

Bagaimana cara menjalankan yarn cache clean di Yarn Classic vs Yarn Berry?

Di Klasik v1, jalankan yarn cache clean, lalu yarn install. Periksa path dengan yarn cache dir. Di Berry, jalankan yarn config get enableGlobalCache (Yarn 4+ default true; Yarn 2 dan 3 default false). yarn cache clean membersihkan scope cache yang aktif. Gunakan yarn cache clean --all untuk scope aktif plus mirror jika diaktifkan; mungkin masih meninggalkan cache global atau proyek lain di disk. Gunakan --mirror hanya jika mirror terpisah ada.

Apakah aman untuk membersihkan cache Yarn?

Ya untuk pengembangan normal. Membersihkan menghapus arsip paket yang diunduh, bukan source aplikasi Anda. Install berikutnya mungkin memakan waktu lebih lama. Di Classic, yarn cache dir menampilkan folder cache ber-versi, tetapi yarn cache clean menghapus root cache induk. Periksa induk tersebut dan gunakan cache-folder jika Anda mengustomisasinya. Di Berry, jalankan yarn config get cacheFolder sebelum pembersihan penuh. yarn cache clean dan yarn cache clean --all menghapus seluruh direktori cache efektif. Dengan enableGlobalCache: false, path tersebut biasanya ./.yarn/cache, tetapi kustom cacheFolder kustom dapat menargetkan parent seperti .yarn dan menghapus file proyek lain yang disimpan di sana. Ketika mirror terpisah diaktifkan, yarn cache clean --all juga menghapus cache di bawah globalFolder. Jalankan yarn config get globalFolder sebelum --all jika path tersebut mungkin menyimpan file lain. Anggap pembersihan penuh sebagai langkah debugging, bukan pemeliharaan harian.

Kapan sebaiknya Anda menghindari pembersihan cache Yarn di CI atau Docker?

Lewati penghapusan cache rutin jika instalasi lambat tetapi lockfile sudah benar. Perbaiki cache key, jalur restore, dan urutan layer Docker terlebih dahulu. Bersihkan cache hanya jika ada bukti artefak paket yang usang atau rusak, bukan sebagai langkah retry default.

Bagaimana cara memverifikasi di mana Yarn menyimpan cache?

Di Klasik v1, jalankan yarn cache dir. Pada Berry, jalankan yarn config get cacheFolder, yarn config get enableGlobalCache, dan yarn config get globalFolder ketika mirror atau yarn cache clean --all sedang digunakan. Pastikan user yang menjalankan Yarn memiliki kepemilikan direktori tersebut di CI dan container.

Mengapa paket lama tetap ada setelah yarn cache clean?

Pembersihan spesifik dapat meninggalkan file di folder sementara seperti cache/.tmp pada versi Yarn lama. Di Classic, jalankan yarn cache clean tanpa nama paket, lalu yarn install. Di Berry, gunakan yarn cache clean --all, hapus node_modules jika perlu, instal ulang, dan periksa jalur temp jika satu paket masih merujuk ke versi lama.

Jika tim Anda merilis aplikasi Capacitor dan butuh release pipeline yang lebih bersih setelah ada masalah dependency atau build, Capgo adalah salah satu opsi untuk mengirim update JavaScript dan asset tanpa menunggu review store, sekaligus menjaga proses build dan rollout tetap terpisah dari troubleshooting package-cache.