Ruang kerja

Ruang kerja adalah cara baru untuk menata arsitektur paket Anda yang tersedia secara default mulai dari Yarn 1.0. Hal ini memungkinkan Anda untuk men-setup beberapa paket sedemikian rupa sehingga Anda hanya perlu menjalankan ` thread install </ code> sekali untuk menginstal semuanya dalam satu pass.</p>

Mengapa Anda ingin melakukan ini?

  • Ketergantungan Anda dapat dihubungkan bersama, yang berarti bahwa ruang kerja Anda dapat saling bergantung satu sama lain sambil selalu menggunakan kode terbaru yang tersedia. Ini juga merupakan mekanisme yang lebih baik daripada link benang </ code> karena hanya mempengaruhi pohon kerja Anda daripada keseluruhan sistem Anda.</p></li>

  • Semua dependensi proyek Anda akan dipasang bersamaan, memberi Yarn lebih lintang untuk mengoptimalkannya dengan lebih baik.

  • Yarn akan menggunakan single lockfile daripada yang berbeda untuk setiap proyek, yang berarti lebih sedikit konflik dan ulasan yang mudah.

  • </ul>

    Bagaimana cara menggunakannya?

    Tambahkan yang berikut ini di file package.json </ code> . Mulai sekarang, kita akan memanggil direktori ini sebagai "root workspace":</p>

    paket.json

    {
      "private": true,
      "workspaces": ["workspace-a", "workspace-b"]
    }
    `</pre> 
    
    Perhatikan bahwa ` private: true </ code> diperlukan! Ruang kerja tidak dimaksudkan untuk dipublikasikan, jadi kami telah menambahkan tindakan pengaman ini untuk memastikan tidak ada yang bisa secara tidak sengaja mengeksposnya.</p>
    
    

    Setelah file ini dibuat, buat dua subfolder baru bernama workspace-a </ code> dan workspace-b </ code> . Di masing-masing, buat file package.json </ code> dengan konten berikut:</p>

    ruang kerja-a / package.json:

    {
      "name": "workspace-a",
      "version": "1.0.0",
    
      "dependencies": {
        "cross-env": "5.0.5"
      }
    }
    `</pre> 
    
    **ruang kerja-b / package.json:**
    
    ```json
    {
      "name": "workspace-b",
      "version": "1.0.0",
    
      "dependencies": {
        "cross-env": "5.0.5",
        "workspace-a": "1.0.0"
      }
    }
    ```
    
    Akhirnya, jalankan ` yarn install </ code> di suatu tempat, idealnya di dalam ruang kerja root. Jika semuanya bekerja dengan baik, sekarang Anda harus memiliki hirarki file yang serupa:</p>
    
    
    /package.json
    /yarn.lock
    
    /node_modules
    /node_modules/cross-env
    /node_modules/workspace-a -> /workspace-a
    
    /workspace-a/package.json
    /workspace-b/package.json
    `</pre> 
    
    Dan itu dia! Membutuhkan ` workspace-a </ code> dari sebuah file yang berada di  workspace-b </ code> sekarang akan menggunakan kode yang tepat yang saat ini berada di dalam proyek Anda daripada yang dipublikasikan di Github, dan  paket cross-env </ code> telah dikosongkan dengan benar dan dimasukkan ke akar proyek Anda untuk digunakan oleh area kerja  -de </ code> dan  -b </ code> .</p>
    
    

    Bagaimana itu dibandingkan dengan Lerna?

    Ruang kerja benang adalah jenis primitif tingkat rendah yang dapat digunakan alat seperti Lerna (dan do !). Mereka tidak akan pernah mencoba untuk mendukung fitur tingkat tinggi yang ditawarkan Lerna, namun dengan menerapkan logika inti dari resolusi dan langkah-langkah penghubung di dalam Yarn itu sendiri, kami berharap dapat memungkinkan penggunaan baru dan meningkatkan kinerja.

    Tips & amp; Trik

    • The ruang kerja </ code> lapangan adalah array yang berisi jalan untuk setiap ruang kerja. Karena mungkin membosankan untuk melacak masing-masing, bidang ini juga menerima pola glob! Sebagai contoh, Babel mereferensikan semua paket mereka melalui satu packages / * </ code> directive.</p></li>

    • Ruang kerja cukup stabil untuk digunakan dalam aplikasi berskala besar dan tidak boleh mengubah apapun sesuai cara kerja pemasangan biasa, namun jika Anda menganggapnya melanggar sesuatu, Anda dapat menonaktifkannya dengan menambahkan baris berikut ke file Yarnrc Anda:

      ruang kerja-percobaan palsu
      `</pre></li> </ul> 
      
      ### Keterbatasan & amp; Peringatan 
      
      * Tata letak paket akan berbeda antara ruang kerja Anda dan apa yang pengguna Anda akan dapatkan (dependensi workspace akan diangkat lebih tinggi ke dalam hirarki filesystem). Membuat asumsi tentang tata letak ini sudah berbahaya karena proses pengangkatan tidak distandarisasi, jadi secara teoritis tidak ada yang baru di sini.
      
      * Pada contoh di atas, jika ` workspace-b </ code> bergantung pada versi yang berbeda dari yang direferensikan di paket  workspace-a </ code> package.json, dependensi akan terinstal dari Github agak daripada terhubung dari filesystem lokal Anda. Ini karena beberapa paket sebenarnya perlu menggunakan versi sebelumnya untuk membangun yang baru (Babel adalah salah satunya).</p></li>
      
    • Be careful when publishing packages in a workspace. If you are preparing your next release and you decided to use a new dependency but forgot to declare it in the package.json` file, your tests might still pass locally if another package already downloaded that dependency into the workspace root. However, it will be broken for consumers that pull it from a registry, since the dependency list is now incomplete so they have no way to download the new dependency. Currently there is no way to throw a warning in this scenario. * Workspaces must be children of the workspace root in terms of folder hierarchy. You cannot and must not reference a workspace that is located outside of this filesystem hierarchy. * Nested workspaces are not supported at this time.