berdasarkan blog benang :

Saat Anda menerbitkan paket yang berisi yarn.lock, setiap pengguna pustaka tersebut tidak akan terpengaruh olehnya. Saat Anda menginstal dependensi di aplikasi atau pustaka Anda, hanya file yarn.lock Anda sendiri yang dihormati. Lockfiles dalam dependensi Anda akan diabaikan.

tampaknya tidak perlu untuk menggabungkan yarn.lock saat menerbitkan paket individual... ini lebih merupakan artefak pengembangan untuk seluruh repo, oleh karena itu, tidak perlu memasukkannya ke dalam setiap paket.

@connectdotz mungkin tidak diperlukan untuk perpustakaan atau paket yang diterbitkan tetapi untuk membangun wadah buruh pelabuhan yang Anda ingin gunakan di suatu tempat pasti akan.

tapi bukankah wadah buruh pelabuhan pengembangan hanya memiliki seluruh repo dan oleh karena itu yarn.lock tetap? Saya dapat melihat kami menggunakan wadah buruh pelabuhan untuk menguji proyek monorepo kami untuk OS atau platform yang berbeda, dalam hal ini kami hanya menggunakan seluruh repo dan yarn.lock-nya. Bisakah Anda memberi saya contoh kasus penggunaan yang Anda perlukan untuk menyebarkan paket individual dari proyek monorepo ke dalam wadah buruh pelabuhan selama siklus pengembangan, jadi saya bisa mendapatkan pemahaman yang lebih konkret ...

Jadi bagi kami, kami tidak ingin mengemas seluruh monorepo ke dalam wadah buruh pelabuhan yang dihasilkan. Kami menggunakan buruh pelabuhan dalam produksi dan gambar-gambar itu harus seringan mungkin. Mono repo kami cukup besar dan berisi beberapa layanan mikro yang berbagi kode di antara mereka menggunakan paket perpustakaan (dan beberapa perpustakaan relevan untuk beberapa layanan mikro, tetapi tidak semua). Jadi ketika kami mengemas layanan mikro, kami ingin gambar berisi file layanan mikro itu dan dependensi lainnya sebagai dependensi yang tepat - diunduh dari registri pribadi kami, dan dibuat untuk lengkungan gambar buruh pelabuhan.

Jadi saya pikir pertimbangan utama di sini adalah untuk menjaga gambar buruh pelabuhan kita seringan mungkin, dan mengemas seluruh monorepo tidak sesuai dengan kebutuhan kita. Juga, ketika kami menjalankan "benang" di dalam gambar layanan mikro, kami tidak ingin memiliki symlink di sana, hanya ketergantungan normal.

Solusinya di sini tidak harus membuat file yarn.lock per ruang kerja, itu juga bisa berupa perintah yarn, yang membantu dalam proses pengemasan ruang kerja tertentu, menghasilkan file yarn.lock untuk ruang kerja sesuai permintaan, dll. ..

Semoga membantu memperjelas kasus penggunaan..

@netanelgilad terima kasih untuk detailnya, ini membantu memperjelas bahwa kasus penggunaan Anda lebih banyak tentang menerbitkan paket individual, untuk produksi atau pengembangan, ke wadah buruh pelabuhan. Silakan bergabung dengan diskusi di #4521 sehingga kami dapat mulai mengkonsolidasikannya.

Meskipun saya dapat melihat penggunaan file kunci individual, itu tidak diperlukan. Jika Anda menjalankan buruh pelabuhan dari root repo dengan flag -f menunjuk ke file individual, Anda akan memiliki seluruh repo sebagai konteks dan dapat menyalin package.json dan yarn.lock dari root.

Anda hanya memerlukan package.json untuk paket yang akan Anda buat dalam gambar dan yarn hanya akan menginstal paket untuk file package.json yang telah Anda salin meskipun Anda yarn.lock menyertakan lebih banyak lagi.

EDIT: Dengan itu. itu menyebabkan cache buruh pelabuhan tidak digunakan untuk perubahan paket dalam paket apa pun meskipun tidak termasuk dalam build

4206 terkait/duplikat, dan kasus penggunaan yang dijelaskan di sana persis dengan masalah yang kami hadapi:

Katakanlah kita memiliki sepuluh paket berbeda. Kami ingin semuanya tinggal di repositori mereka sendiri sehingga orang dapat mengerjakannya secara mandiri jika mereka mau, tetapi kami juga ingin dapat menautkannya bersama jika perlu. Untuk melakukan ini, kami memiliki repositori mega dengan submodul untuk setiap paket, dan package.json yang mereferensikan masing-masing submodul ini sebagai ruang kerja.

Saya memiliki masalah serupa dengan ruang kerja. Proyek saya adalah web-app yang bergantung pada banyak paket lokal:

web-app/
|--node_modules/
|--packages/
|  |--controls/
|  |  |--src/
|  |  |--package.json
|  |--utils/
|     |--src/
|     |--package.json
|--src/
|--package.json
|--yarn.lock

Paket ruang kerja controls dan utils tidak dipublikasikan dan digunakan oleh jalur. Masalahnya adalah saya perlu merilis paket controls ( yarn pack ) dan saya tidak ingin membangun/mengujinya sendiri. Itu berarti saya ingin melakukan yarn install di dalam web-app/packages/constols/ . Dengan ruang kerja itu akan menggunakan file web-app/yarn.lock tingkat atas bersama-sama dengan tingkat atas web-app/node-modules/ . Jadi, Ini menginstal semua paket alih-alih subset, yang ditentukan dalam web-app/packages/controls/package.json . Tetapi saya perlu memeriksa apakah paket saya memiliki semua dependensi yang diperlukan di dalam package.json dan tidak berfungsi dengan keberuntungan mengisi deps yang hilang dari ruang kerja lain.

Ada 2 kemungkinan solusi:

1. Jika bukan root, gunakan yarn.lock root, tetapi instal hanya paket yang ditentukan di package.json .
2. Jangan mencari konfigurasi tingkat atas, tetapi .yarnrc/.npmrc .

Juga berjuang dengan ini. Kami memiliki proyek Angular CLI di samping API kami sehingga mereka berada di repositori yang sama dan mencoba untuk mendorong frontend ke Heroku.

Kami menggunakan buildpack yang memberi tahu Heroku untuk melompat ke repositori frontend terlebih dahulu: https://github.com/lstoll/heroku-buildpack-monorepo

Masalahnya adalah, tidak ada yarn.lock di dalam paket nohoist jadi Heroku hanya menginstal dengan npm dan kami berakhir dengan semua paket baru daripada yang terkunci

Anda bisa menggunakan file yarn.lock global dengan paket individual. Saya baru-baru ini mendekati Dockerfile saya seperti ini:

WORKDIR /app
ENV NODE_ENV=production

ADD yarn.lock /app/
ADD package.json /app/

# Only copy the packages that I need
ADD packages/my-first-package /app/packages/my-first-package
ADD packages/my-second-package /app/packages/my-second-package

RUN cd /app && yarn install --frozen-lockfile

Ini hanya akan menginstal dependensi yang benar-benar digunakan oleh dua paket yang saya salin dan bukan oleh orang lain.

Saya memiliki proses pembuatan di mana pertama saya ingin membuat artefak rilis dari satu paket dan kemudian tidak menginstal dependensinya. Ini cukup mudah dengan build multistage Docker

1. Tambahkan hanya yarn.lock, package.json dan paket UI ke buruh pelabuhan
2. jalankan yarn install --frozen-lockfile
3. menjalankan proses pembuatan
4. mulai tahap baru dan tambahkan yarn.lock, package.json dan folder paket/ruang kerja runtime yang diperlukan
5. Lakukan COPY --from=<stage> untuk artefak yang dibuat
6. jalankan yarn install --frozen-lockfile dan buka perintah RUN .

Dan Anda akan berakhir dengan wadah kecil yang hanya berisi dependensi yang ditentukan dalam file yarn.lock Anda dan diperlukan dalam produksi.

@johannes-scharlach
Saya akhirnya menggunakan metode yang hampir identik dengan apa yang Anda gambarkan. build multistage adalah tip yang bagus :).

@connectdotz Saya pikir dari pihak saya, masalah ini dapat diselesaikan dan kami dapat terus mengerjakan masalah #4521. Karena file yarn.lock utama dapat bekerja dengan subset dari paket, sepertinya yarn.lock per ruang kerja tidak diperlukan (walaupun saya masih berpikir ini bisa menjadi alur kerja dev yang lebih baik ). Tetapi masalah di #4521 masih penting, karena dalam solusi yang kita dapatkan di sini, kita perlu menyebutkan setiap ruang kerja dependensi di Dockerfile meskipun benang harus mengetahui interdependensi dan bagaimana "vendor" ruang kerja yang diberikan.

Saya menghabiskan beberapa hari terakhir mencoba mengonversi monorepo kami ke ruang kerja Lerna pertama dan kemudian Benang. Benang bekerja secara umum lebih andal dan sangat mendekati apa yang kami butuhkan, terutama dengan diperkenalkannya yarn workspaces run <script> dan hal-hal baik lainnya seperti wsrun .

Namun, yarn.lock tunggal adalah titik sakit:

• Saya tidak yakin bagaimana cara memigrasikan file kunci yang ada dengan benar ke satu file, lihat https://github.com/yarnpkg/yarn/issues/6563. Kami memiliki puluhan ribu baris di sana dan menambahkan paket yang ada saat ruang kerja memperkenalkan banyak masalah versi yang halus.
• Menginstal dependensi dalam paket tertentu saja ("de-hoisting" / "vendoring") Build yang di-docker tidak didukung dengan baik, lihat di atas (https://github.com/yarnpkg/yarn/issues/5428#issuecomment-403722271) atau https: //github.com/yarnpkg/yarn/issues/4521.

Apa pendapat Anda tentang ruang kerja Yarn yang hanya merupakan inti kecil – deklarasi paket tanpa fungsi khusus apa pun. Sebagai contoh:

• Jika Anda ingin menjalankan beberapa skrip di seluruh ruang kerja Anda, Anda akan melakukannya yarn workspaces run <script> .
• Jika Anda menginginkan satu file kunci dan mengangkat (apakah keduanya harus diikat bersama?), ini akan menjadi root Anda package.json :
  json "workspaces": { "packages": ["packages/*"], "hoistDependencies": true }
• Jika Anda ingin memigrasi file kunci Anda saat ini ke struktur yang diangkat, Anda akan menjalankan yarn workspaces hoist-dependencies .

Dll Ini hanya contoh dan dalam prakteknya, beberapa fitur mungkin akan opt-out bukannya opt-in (misalnya, orang-orang berharap satu yarn.lock dan hoisting sekarang) tetapi ide umum adalah bahwa ruang kerja akan menjadi fondasi yang ringan untuk tugas-tugas repo-lebar.

Bagaimana menurutmu?

Saya yakin masalah yang ditangani oleh permintaan fitur ini sama seperti di #4521 . Perintah untuk melakukan apa yang pada dasarnya dijelaskan oleh @johannes-scharlach pasti akan lebih layak daripada lockfile per ruang kerja.

Ada juga RFC yang terbuka sekarang untuk ruang kerja bersarang , yang terdengar mirip dengan permintaan fitur ini meskipun saya yakin ini memecahkan masalah yang berbeda.

Apa pendapat Anda tentang ruang kerja Benang yang hanya merupakan inti kecil – deklarasi paket tanpa fungsi khusus apa pun?

Ruang kerja tidak akan berubah secara drastis, saya pikir kami puas dengan antarmuka mereka saat ini.

Jika Anda ingin menjalankan beberapa skrip di seluruh ruang kerja Anda, Anda akan melakukan yarn workspaces run <script>

Itu sudah mungkin (v1.10, #6244).

Jika Anda ingin memigrasi file kunci Anda saat ini ke struktur yang diangkat, Anda akan menjalankan yarn workspaces hoist-dependencies .

Karena kita tidak akan mengubah antarmuka ruang kerja, itu akan menjadi kebalikannya ( dehoistDependencies ).

Yang tidak saya sukai dari ini adalah dibutuhkan perilaku teknis (mengangkat) dan mencoba mengubahnya menjadi perilaku semantik. Anda harus fokus pada cerita pengguna dan kemudian mencari tahu implementasinya daripada sebaliknya.

Dalam hal ini, saya pikir kasus penggunaan Anda ("Menginstal dependensi hanya dalam paket tertentu") akan lebih baik diselesaikan dengan memperluas yarn --focus .

Saya kira pertanyaan intinya adalah apakah mengangkat dan satu file yarn.lock benar-benar diperlukan untuk ruang kerja. Maksud saya, apakah yang benar-benar mendefinisikan mereka atau "hanya" fitur pertama yang mereka dapatkan secara historis?

Misalnya, dalam kasus penggunaan kami, perilaku hipotetis terbaik dari ruang kerja adalah:

• Kerek node_modules pada waktu pengembangan untuk efisiensi.
• Simpan file yarn.lock untuk build (kami membuat paket khusus di Docker, sesuatu yang juga disebutkan orang lain di utas ini) dan juga agar paket dapat mengunci versi spesifiknya. Lihat juga #6563.
• Jalankan skrip melalui yarn workspaces run <script> bahkan jika Anda tidak perlu (atau harus menghindari) pengangkatan.

Pengangkatan dapat dinonaktifkan dengan nohoist , run dapat "dinonaktifkan" hanya dengan tidak menggunakan perintah tetapi tidak mungkin untuk "menonaktifkan" file yarn.lock tunggal, dan saya' saya tidak yakin apakah itu fitur inti sehingga tidak dapat dinonaktifkan atau apakah itu belum cukup diminta :)

Saya pikir cara terbaik untuk menyelesaikan ini adalah dengan memiliki yarn install --app-mode package@version

Dengan begitu, Anda cukup menyalin file kunci ruang kerja saat memublikasikan aplikasi Anda pada versi tertentu, dan menginstal di app-mode akan menghormati file kunci yang dibundel.

Benang tidak harus menginstal seluruh file kunci; itu harus dengan mudah dapat mengekstrak hanya bagian dari grafik ketergantungan yang relevan dengan paket itu.

Sebenarnya ini mungkin cukup mudah dilakukan secara manual bahkan sekarang:

• unduh paket Zip dari registri secara langsung (benang tidak memiliki padanan, npm tidak: npm pack package@version )
• ekstrak gzip ke node_modules/package
• cd ke node_modules/paket
• jalankan yarn install --production dari sana (itu akan menghormati file kunci yang dibundel)

edit: sayangnya ini semua salah, karena file kunci ruang kerja tidak menyertakan versi paket di dalam ruang kerja, yang mungkin merupakan dependensi dari paket aplikasi. Perlu ada sesuatu yang lebih terlibat daripada menyalin saat membuat file kunci aplikasi dari file kunci ruang kerja.

Saya tidak yakin apakah file kunci yang terpisah adalah jawabannya, tetapi saya memiliki masalah yang sama. Saya memiliki pengaturan monorepo dengan CLI dan backend. CLI memerlukan beberapa paket yang spesifik untuk platform dan hanya berfungsi pada mesin desktop dengan pengaturan tertentu. Di sisi lain saya harus dapat membangun api saya menjadi gambar buruh pelabuhan, yang pada dasarnya tidak mungkin dalam implementasi ruang kerja saat ini.

Kasus penggunaan yang sangat mirip dengan @samuela di sini! Yang satu ini akan sangat membantu!

Kasus penggunaan saya mungkin tampak menggelikan dibandingkan dengan yang lain, yang "nyata". Tetapi saya memiliki monorepo untuk beberapa utilitas - dalam kasus ini, kait reaksi - di dalam packages/* .

Saya memiliki ruang kerja kedua di sebelah packages/* , dan itu adalah local/* . Ini sebenarnya ada di gitignore, dan idenya adalah pengembang di perusahaan dapat melakukan apa pun yang mereka suka di sana, misalnya menempatkan aplikasi create-react-app di sana dan menguji kait selama pengembangan.

Sekarang, meskipun paket local/* ada di gitignore, root yarn.lock hanya membengkak dan tercemar - dan diperiksa ke git - karena ruang kerja lokal.

Apa yang saya inginkan adalah cara untuk menentukan bahwa beberapa ruang kerja akan menggunakan beberapa file kunci tertentu, misalnya beberapa pemetaan seperti:

  "workspaces": {
    "packages": [
      "packages/*",
      "local/*"
    ],
    "lockfiles": {
      "local/*": "./local.yarn.lock"
    }
  }

Atau bahkan cara untuk menentukan "jangan memasukkan apa pun dari ruang kerja _this_ ke dalam file kunci sama sekali".

Tapi ya, saya bukan kasus penggunaan yang serius sejak awal :)

Saya tidak yakin apakah file kunci yang terpisah adalah jawabannya, tetapi saya memiliki masalah yang sama. Saya memiliki pengaturan monorepo dengan CLI dan backend. CLI memerlukan beberapa paket yang spesifik untuk platform dan hanya berfungsi pada mesin desktop dengan pengaturan tertentu. Di sisi lain saya harus dapat membangun api saya menjadi gambar buruh pelabuhan, yang pada dasarnya tidak mungkin dalam implementasi ruang kerja saat ini.

Anda berhasil – seperti yang saya lihat, salah satu manfaat inti dari file yarn.lock adalah untuk membuat build produksi beku-dep! Apakah pencipta Benang melupakan itu?

Argumen lain untuk memecahkan masalah lockfile tunggal adalah kepemilikan kode. Jika Anda memiliki monorepo yang menggunakan sesuatu seperti fitur GitHub CODEOWNERS, tidak mungkin memberikan kepemilikan penuh atas sebuah paket kepada sekelompok pengembang. Itu karena jika mereka menginstal sesuatu di ruang kerja mereka sendiri, mereka akan selalu mengubah file kunci tingkat root. Perubahan ini perlu disetujui oleh pemilik kode dari file kunci, yang, jika diberikan monorepo dengan skala yang cukup, akan berbeda dari pemilik ruang kerja asli.

Namun alasan lain untuk memiliki opsi untuk menghasilkan file kunci per ruang kerja: Google App Engine menolak untuk meluncurkan layanan Node tanpa file kunci (NPM/Benang). Ini adalah pengembangan yang sangat baik di pihak mereka, tetapi menyakitkan bagi kami. Sejauh ini opsi yang kami miliki adalah:

• Terapkan semua dengan env vars yang menunjukkan layanan mana yang kami maksud dan ubah yarn start (satu-satunya titik masuk yang didukung) ke cabang berdasarkan env vars
• Minta skrip build menyalin file kunci utama ke setiap ruang kerja dan terapkan hanya layanan yang kami minati. (terima kasih @johannes-scharlach)

Pada akhirnya saya pikir perintah yarn install --workspace-lockfile yang dihasilkan per file kunci ruang kerja akan menjadi solusi terbaik.

Memiliki opsi untuk file kunci tingkat paket akan membantu kami juga. Kasus penggunaan kami sedikit berbeda, kami mencoba cara baru untuk mengelola dependensi lokal.

Jadi kami sudah memiliki beberapa repo mono, dan kami memiliki beberapa repo yang hanya berisi satu paket. Ini semua diterbitkan dan dapat digunakan bersama-sama, namun ada banyak waktu ketika memilikinya secara lokal dan symlink sangat berguna.

Tetapi beberapa pengembang mengalami kesulitan mengelola symlink dll dan jadi kami mencoba repo mono ruang kerja benang kosong standar yang kami semua klon ke mesin kami, lalu kami mengkloning repo paket ke repo mono lokal itu. Beberapa dari kita mungkin hanya memiliki satu klon paket, beberapa mungkin memiliki 5. Ini sangat nyaman dan membuat pengembangan lokal, repo silang, ketergantungan silang menjadi sangat mudah.

Tetapi kami menemukan satu masalah yang tidak dapat kami selesaikan, mengedit dependensi tidak memperbarui file kunci benang lokal, selalu memperbarui yang root untuk repo mono kosong yang tidak kami perbarui pembaruan dependensi (ada semuanya di bawah /packages diabaikan.

Memiliki opsi untuk tidak mengerek file kunci yang ditulis ke root mono repo akan sangat bagus dan meminta mereka menulis di tingkat paket.

Sebagai catatan, saya juga menemukan masalah penyebaran dan pembangunan di sekitar Docker yang telah disebutkan orang lain dan ini akan menyelesaikannya juga!

Fitur ini akan sangat berharga bagi saya juga. Dalam kasus saya, saya memiliki monorepo dengan beberapa paket yang dikerahkan ke platform yang berbeda. Salah satunya adalah aplikasi Next.js yang di-deploy dengan Now.sh dan yang lainnya adalah sekumpulan fungsi cloud yang di-deploy ke Firebase.

Dalam kedua penerapan ini, kode sumber dibundel dan diunggah untuk dipasang & dibangun di cloud. Tidak memiliki file yarn.lock untuk disertakan dengan sumber berarti dependensi diinstal menggunakan versi di package.json dan tidak ada versi yang dikunci.

Saya juga ingin dapat mengaktifkan file yarn.lock di setiap ruang kerja.

Saya menyadari ruang kerja benang sebagian besar ditujukan untuk monorepos, tetapi kasus penggunaan kami jika sangat mirip dengan @LeeCheneler .

Pada dasarnya, kami telah membuat pustaka komponen React yang kami gunakan sebagai dependensi dalam proyek yang berbeda (yang semuanya memiliki repo sendiri). Dengan menggunakan ruang kerja benang, kami dapat dengan mudah mereferensikan versi lokal dari pustaka komponen dan memiliki perubahan yang menyebar ke versi lokal dari proyek kami yang lain dengan cepat. Kami juga tidak perlu memodifikasi package.json saat kami mendorong ke produksi karena dependensi library: "*" bekerja tanpa perubahan apa pun. Satu-satunya masalah kami adalah, tanpa file kunci benang, versi produksi setiap proyek dapat berakhir dengan menggunakan versi paket yang berbeda.

Saya harus membayangkan bahwa masalah ini akan umum di antara semua pengembang paket yang menggunakan ruang kerja benang.

Masalah kritis lainnya dengan lockfile tingkat atas adalah bahwa ia merusak cache lapisan Docker. Seseorang biasanya dapat mengoptimalkan caching Docker dengan terlebih dahulu menyalin package.json dan yarn.lock. Jika Docker tidak melihat perubahan pada file-file itu, itu akan menggunakan lapisan sebelumnya. Namun, jika lockfile itu adalah satu untuk seluruh monorepo, perubahan apa pun dalam paket apa pun akan membuat cache menjadi tidak valid. Bagi kami, ini menghasilkan pipeline CI/CD yang sangat lambat di mana setiap paket dibuat tanpa cache. Ada alat lain, seperti Lerna, yang memeriksa perubahan paket untuk menjalankan skrip tertentu. Ini juga rusak karena perubahan ketergantungan di lockfile mungkin tidak diambil karena berada di tingkat atas.

Maaf untuk mengemukakan masalah (sedikit lama) ini, tetapi saya juga memiliki kasus penggunaan di mana ini akan membantu. Saya memiliki 10 atau lebih layanan mikro yang di-host dan dikembangkan secara independen tetapi akan menyenangkan untuk memiliki repo ruang kerja pusat di mana Anda dapat mengetik yarn install untuk menginstal dependensi di semua folder dan kemudian menjalankan yarn start untuk menjalankan skrip yang akan memulai semua layanan mikro. Ini adalah sesuatu yang dapat dilakukan dengan skrip yang relatif sederhana tetapi tampaknya juga dapat dilakukan dengan ruang kerja benang tetapi saya tidak dapat membuatnya bekerja sambil menghormati yarn.locks di setiap layanan mikro

@nahtnam Saya pikir ide Benang 1.x monorepo sedikit berbeda. Ini bukan tentang proyek independen di bawah satu atap, ini lebih tentang proyek besar tunggal yang beberapa komponennya terbuka (disebut ruang kerja). Komponen-komponen ini tidak sepenuhnya independen, tetapi dapat digunakan seperti ini: kompiler Babel sebagai satu entitas yang lebih besar dan preset-env sebagai sub-modul. Juga, mereka homogen dalam arti bahwa dependensinya disatukan: jika beberapa paket bergantung pada core-js , itu harus sama core-js versi di setiap paket, karena Anda tidak bisa mengunci versi yang berbeda dengan satu file kunci root, juga tidak masuk akal jika bagian proyek bergantung pada versi yang berbeda. Dan karena ini adalah satu proyek, semua komponennya secara otomatis ditautkan ke root node_modules , yang aneh untuk proyek yang sepenuhnya independen.

Jadi, jika Anda mengembangkan paket layanan mikro (yang independen, dan beberapa di antaranya tidak akan disentuh selama bertahun-tahun sementara yang lain akan dibuat/diperbarui, mungkin dikembangkan oleh tim yang berbeda), maka mereka harus memiliki file kunci pribadi tanpa root lock (Masalah Docker juga ada di sini). Satu-satunya pertanyaan adalah alat apa yang akan membantu menjalankan skrip. Lerna mungkin menjadi jawaban karena tidak terikat pada Benang.

Satu-satunya pertanyaan adalah alat apa yang akan membantu menjalankan skrip. Lerna mungkin menjadi jawaban karena tidak terikat pada Benang.

@the-spyke Tidak hanya itu. yarn workspaces juga memecahkan, menautkan modul untuk pengembangan dengan cara yang sama seperti yang dilakukan npm link , yang merupakan alasan utama kami menggunakannya. npm link tidak berfungsi dengan baik dalam beberapa kasus.

@the-spyke Terima kasih! Untuk beberapa alasan, saya pikir itu terbalik (ruang kerja lerna vs benang). Saya melihat ke lerna dan sepertinya itu menyelesaikan masalah saya

Saya akhirnya menggunakan ruang kerja untuk setiap proyek yang sedang saya kerjakan, karena betapa mudahnya memiliki paket utilities yang dapat saya perbarui saat dibutuhkan (walaupun sudah diterbitkan), dan fakta bahwa Saya tidak perlu menginstal ulang dependensi jika saya ingin melakukan fork beberapa paket (pada dasarnya memungkinkan saya untuk bekerja di dua cabang secara bersamaan, yang bagi saya tidak pernah terdengar), dan setiap kali saya ingin menggunakan paket dari utilities (yang mencakup sebagian besar hal yang biasanya saya gunakan), saya dapat langsung menggunakannya tanpa menambahkannya ke package.json dari paket kedua (tapi itu jelas merupakan ide yang bagus untuk instalasi terpisah, dan diperlukan untuk impor IDE otomatis); semuanya hanya bekerja. @the-spyke membuat poin yang bagus, mungkin independent projects under one roof bukan tujuan dari ruang kerja, namun itulah yang tampaknya saya lakukan di sini: Saya memiliki repositori monorepo-base tunggal, yang tidak termasuk folder packages , sementara setiap folder di bawah packages adalah repo git independen yang terpisah.

Tentu saja itu membawa saya ke topik utas ini; karena saya tidak mengkomit semua paket sebagai satu repo, level root yarn.lock tidak ada artinya. Saya telah menggunakan --no-lockfile untuk menginstal semuanya, dan baru-baru ini mengalami masalah dengan versi class-validator bertentangan. Untuk saat ini saya akan mengunci semua deps ke versi tertentu (jujur, tingkat kontrol itu lebih masuk akal bagi saya) dan melihat cara kerjanya. Saya akan membaca seluruh tread lagi, mungkin ada beberapa tips yang bisa saya gunakan untuk use case saya.

PS.
yarn why tidak berfungsi tanpa lockfile untuk satu, dan saya perhatikan beberapa orang menyebutkan masalah dengan App Engine. Saya kira jika setiap paket menjadi repo terpisah, file kunci dapat dibuat setiap kali saat instalasi (tanpa menambahkannya ke VCS)? Tidak yakin tentang kasus khusus itu.

Sayangnya solusi yang disarankan oleh @johannes-scharlach menjadi sangat berantakan jika gambar yang Anda buat memerlukan modul node runtime yang tidak disertakan dalam beberapa folder build, karena Anda harus mengetahui dengan tepat modul apa yang diperlukan untuk dijalankan, dan dengan susah payah menyalinnya ke tahap pembuatan akhir.

(sedikit di luar topik) @GrayStrider Anda juga dapat menggunakan bidang "resolusi" di package.json - ini adalah satu-satunya cara untuk memaksa versi pada ketergantungan bersarang, misalnya jika Anda ingin semua lodash menjadi versi yang tepat, tidak masalah seberapa dalam bersarang. Namun, itu dapat menimbulkan bug yang sangat halus yang akan sulit dikenali..

Berikut adalah solusi yang kami dapatkan - dengan dampak minimal pada alur kerja Docker yang ada.

1. ln project/yarn.lock packages/package1/yarn.lock - buat hard symlink dari root yarn.lock ke dalam setiap paket.
2. Tambahkan COPY yarn.lock . ke setiap packages/package1/Dockerfile
3. yarn install di dalam Docker

Keuntungan :

• Tidak perlu menyalin seluruh monorepo Anda ke dalam lapisan gambar
• Tidak perlu menggabungkan Dockerfile tingkat paket Anda menjadi satu Dockerfile di root
• Pada dasarnya memenuhi persyaratan file kunci ruang kerja

Kekurangan :

• --frozen-lockfile tidak berfungsi. Karena paket ruang kerja tidak disertakan dalam yarn.lock , maka yarn melihat paket yang telah Anda "tambahkan" ke package.json yang tidak ada di yarn.lock

Ini adalah kerugian kecil, karena Anda dapat menyiasatinya dengan melakukan yarn --frozen-lockfile sebagai langkah pertama dalam pipa CI/CD Anda

Sunting:
Selain itu, saya benar-benar berpikir bahwa dokumen benang tentang pemasangan bisa sedikit lebih jelas dengan bagaimana lockfile digunakan oleh proses resolusi paket.

Sunting:
Jadi ternyata git sebenarnya tidak mendukung hard-link, hanya mendukung soft symlink, jadi strategi ini tidak akan berhasil.

Alternatif lain adalah dengan hanya menggunakan githook prakomit untuk menyalin yarn.lock ke setiap ruang kerja Anda... ini tidak ideal karena masih memungkinkan masalah saat menerapkan dari mesin lokal Anda.

@dan-cooke terima kasih banyak atas wawasan Anda, sangat dihargai!

@dan-cooke, ini merusak cache lapisan Docker karena ketergantungan baru di ruang kerja apa pun akan membatalkan lapisan pemasangan untuk semua file Docker.

@migueloller Jika lapisan instalasi tidak boleh berubah, maka Anda tidak boleh menggunakan satu file kunci untuk semua paket. Meratakan dan mengangkat dependensi ke dalam satu daftar raksasa adalah tujuan keseluruhan dari Ruang Kerja. Ini tidak seperti "merusak" cache Docker, cache tidak valid karena dependensi nyata tidak ditentukan dalam package.json , jadi kode akhir paket Anda bergantung pada konten yarn.lock . Akibatnya, Anda perlu membangun kembali semua paket pada setiap perubahan di yarn.lock dan Docker melakukan semuanya dengan benar. Dan tidak seperti where every package is built without the cache karena semua build dapat menggunakan kembali layer dengan yarn install (mungkin Anda perlu mengatur ini).

@migueloller
Benar. Kami untungnya tidak sering menambahkan dependensi baru , jadi ini hanya akan menjadi masalah setelah sprint paling banyak.

Dan bahkan kemudian, itu adalah harga kecil yang harus dibayar (untuk kami) untuk dependensi yang dapat direproduksi di Docker

@the-spyke, memang. Itulah sebabnya masalah ini adalah tentang memiliki file kunci individual per paket. Dengan cara ini, lapisan yang di-cache hanya menjadi tidak valid ketika dependensi paket berubah dan tidak bergantung pada paket lain.

Mungkin ada baiknya juga memindahkan diskusi ini ke npm itu sendiri, yang mendukung ruang kerja juga dimulai dengan v7.0..

Saya telah meneliti topik terkait dan ingin menambahkan beberapa klarifikasi pada komentar saya di atas (sebagian besar ditujukan untuk pengembang yang kurang berpengalaman, saya kira, karena masalah yang saya hadapi sampai batas tertentu karena kegagalan saya dalam memahami pentingnya lockfile ).

"mengunci semua dependensi ke versi tertentu" disebut pinning ; sayangnya, itu tidak akan mencegah hal-hal yang berpotensi rusak jika pembaruan sub- dependensi (paragraf terakhir artikel di sini ), yang belum saya pertimbangkan. Itulah tepatnya yang dimaksudkan lockfile untuk mencegah agar tidak terjadi.

Saya telah menghabiskan lebih dari cukup waktu untuk memecahkan pembaruan di masa lalu pada beberapa kesempatan; Saya akan bereksperimen dengan menggunakan lockfile di monorepo, karena saya lebih suka menangani konflik gabungan dan sakit kepala organisasi, daripada bug tak terlihat yang disebabkan oleh pembaruan kecil.

Di atas dikatakan, saya sangat menantikan kemajuan apa pun dalam masalah ini

@migueloller File kunci individual berarti Monorepos Benang individual. Anda tidak dapat memiliki file kunci untuk Ruang Kerja karena itu merusak keseragaman deps di Monorepo. Jika Anda ingin melakukannya, Anda akan menjauh dari ide asli Benang Monorepo: ini tentang menyatukan, mengangkat, dan mengurangi deps ke dalam daftar datar di root alih-alih memiliki versi yang berbeda (dan bahkan seluruh subpohon) di ruang kerja yang berbeda .

@the-spyke tetapi masalah aslinya adalah kebalikannya. File kunci per ruang kerja.

Saya gagal memahami bagaimana Anda tidak dapat memiliki file kunci per ruang kerja.

Itu merusak keseragaman deps di Monorepo? Tentu untuk pengembangan. Tetapi seluruh tujuan dari dependensi bersama tidak berlaku lagi ketika Anda harus menerapkan layanan mikro ringan dari setiap ruang kerja Anda

Deps yang dibagikan dan diangkat hanya masuk akal dalam pengembangan.

Agar ruang kerja dapat hidup di Docker, diperlukan file kunci.

@dan-cooke Seperti yang Anda lihat , saya juga mengalami masalah ini pada tahun 2018, tetapi sekarang saya memiliki pendapat yang berbeda.

Anda mengatakan Docker dan Layanan Mikro. Tetapi bagaimana jika saya mengembangkan paket npm ? Saya tidak memiliki subpohon dependensi production untuk disematkan, karena mereka akan disediakan oleh pengguna akhir sesuai dengan spesifikasi dependencies . Jadi, yang saya inginkan adalah memaksimalkan pengalaman pengembangan saya, dan itulah yang dilakukan dengan sempurna oleh Monorepos dan Yarn Workspaces.

Saat yang sama, jika Anda mengembangkan layanan mikro (MS) ada 2 kemungkinan situasi:

1. Proyek independen. Beberapa MS sedang dalam pengembangan, beberapa tidak tersentuh selama bertahun-tahun. Dalam hal ini mereka sepenuhnya independen. Dimungkinkan untuk memiliki UserService menggunakan [email protected] dan MessagesService menggunakan [email protected] . Itu bukan dunia yang mudah di mana Anda hanya menautkan folder dari Workspaces ke root node_modules . Jadi, tidak ada gunanya memiliki file kunci root. Buat file terpisah (root) dan kelola secara mandiri. Itu disebut Multirepo di Yarn docs. Tapi sekarang apa yang Anda katakan adalah "Saya ingin menjalankan tugas di folder yang berbeda dari folder root untuk kenyamanan". Dan itu topik yang sama sekali berbeda.

2. Proyek dengan dependensi terpadu seperti Jest/Babel/etc. Untuk inilah Ruang Kerja dibuat, tetapi di MS ada persyaratan tambahan. Selama tahap CI seperti linting dan pengujian semua berfungsi dengan baik karena bekerja sama seperti yang Anda lakukan pada mesin pengembang: deps diinstal oleh Yarn ke root node_modules dan diratakan. Hanya dengan tambahan bahwa Anda mungkin men-cache fase yarn install untuk mempercepat build bersamaan.

   Dalam produksi itu benar-benar berbeda: mulai dari itu Anda hanya perlu deps untuk satu ruang kerja dan diakhiri dengan cara menginstal paket utils ? Haruskah itu ditautkan atau diunduh sebagai tarball? Jadi, yang benar-benar Anda butuhkan bukanlah memiliki file kunci per Ruang Kerja, tetapi memiliki perintah seperti yarn install --prod <workspace> yang dapat Anda jalankan dengan menentukan Ruang Kerja dan itu hanya akan menginstal deps produksi dan pada saat yang sama mengabaikan Ruang Kerja lain yang tidak direferensikan. Seperti jika data WS saya bergantung pada utils WS, tetapi tidak pada logging WS, maka logging itu sendiri dan depsnya tidak akan muncul di node_modules . Hasil yang serupa, tetapi pendekatan yang sama sekali berbeda untuk "file kunci per ruang kerja".

   Jika Anda memublikasikan paket build ke dalam repositori (npm, Arifactory, GutHub), Anda bisa mendapatkan perilaku serupa hanya dengan menyalin file kunci ke dalam Workspace dan melakukan yarn install --prod sini. Seharusnya memperingatkan tentang file yang sudah ketinggalan zaman, tetapi alih-alih membuat ulang jika dari awal dengan versi baru, itu hanya harus menghapus kelebihan deps darinya (baru saja dicoba dan terlihat sah). Harus lebih baik dan kuat dengan menggunakan Offline Mirror.

   Dan pada akhirnya Anda telah menerapkan Ruang Kerja Terfokus persis untuk Multirepos.

Jadi, apa yang saya katakan itu mungkin masalahnya tidak terlihat seperti apa adanya.

@the-spyke
Aku mengerti apa yang kamu ucapkan. Saya pikir itu pasti turun ke bagaimana hasil ini dicapai. Mungkin file kunci per ruang kerja sebenarnya bukan cara terbaik untuk mencapai hasil yang diinginkan. Anda membuat beberapa poin bagus.

Ini jelas bukan solusi "satu ukuran cocok untuk semua"

@the-spyke, Anda mengemukakan poin bagus. Mungkin lebih banyak pemikiran perlu dimasukkan ke dalam masalah apa yang dirancang untuk dipecahkan oleh ruang kerja Benang dan jika menggunakannya untuk mengelola monorepo besar selaras dengan desain itu.

Saya ingin tahu bagaimana Anda akan menyelesaikan skenario seperti ini:

.
└── packages
    ├── app1
    ├── app2
    ├── lib1
    ├── lib2
    └── lib3

lib3 adalah perpustakaan bersama dan bergantung pada app1 dan app2 . lib1 hanya digunakan oleh app1 dan lib2 hanya digunakan oleh app2 . Berdasarkan saran Anda, lib1 dan app1 harus berada di ruang kerja mereka sendiri dengan lockfile mereka sendiri dan sama dengan lib2 dan app2 . Sekarang, pertanyaannya adalah apa yang harus dilakukan dengan lib3 jika _both_ app1 dan app2 bergantung padanya? Mungkin seseorang bisa membuatnya sehingga kedua ruang kerja ( app1 dan app2 ) menambahkan lib3 ke ruang kerja mereka dan kemudian menjalankan yarn install di setiap aplikasi? Apakah Benang mengizinkan ini? Apakah akan ada konflik jika seseorang ingin menjalankan app1 dan app2 dalam pengembangan secara lokal (mungkin app1 adalah aplikasi React dan app2 API GraphQL) ? Ini terdengar seperti itu bisa berhasil.

Pertanyaan berikutnya yang harus diajukan adalah "Bagaimana seseorang mendapatkan manfaat mengangkat dengan metode ini?" Misalnya, jika app1 dan app2 berbagi banyak dependensi umum, akan lebih baik untuk mengangkatnya. Saya dapat melihat bagaimana ini mungkin di luar cakupan, dan merupakan masalah yang harus diselesaikan oleh Yarn PnP (tidak menyalin file ke node_modules dan malah memiliki cache bersama).

Saya akan mencoba ini dan akan melaporkan kembali. Jika ini akhirnya berhasil, maka mungkin kita baru saja menggunakan ruang kerja Benang yang salah selama ini ...

EDIT: Saya mencobanya, dan berhasil.

Saya telah mengubah pendirian saya sekarang dan menyadari bahwa meskipun memiliki file kunci individual per ruang kerja mungkin menjadi hal pertama yang terlintas dalam pikiran ketika mengelola seluruh monorepo dengan ruang kerja Benang, itu mungkin bukan pertanyaan yang tepat. Pertanyaan yang lebih baik mungkin "Apakah ruang kerja Benang dirancang untuk mengelola monorepo?". Jawabannya, seperti biasa, adalah "tergantung".

Jika Anda Babel dan Anda memiliki satu tim yang mengerjakan monorepo dan semuanya dimaksudkan untuk berubah secara berurutan, maka ya, untuk inilah ruang kerja Benang dirancang. Tetapi jika Anda adalah organisasi dengan banyak tim dan Anda menggunakan monorepo, Anda mungkin tidak ingin mengelola seluruh monorepo dengan satu akar ruang kerja Yarn. Anda mungkin hanya ingin menggunakan perilaku default Benang atau beberapa akar ruang kerja Benang di dalam monorepo. Ini akan ditentukan oleh aplikasi apa yang Anda buat, berapa banyak tim yang ada, dll.

Bagi kami, menjadi jelas bahwa untuk setiap entitas yang dapat di-deploy (dalam kasus kami ada Dockerfile), kami ingin membuat yarn install terpisah untuk masing-masing entitas (apakah itu root workapce atau bukan). Ini memberikan kejelasan seputar kepemilikan kode, memungkinkan penerapan terisolasi yang terjadi pada irama yang berbeda, memecahkan masalah caching dengan lockfiles dan Docker, dll. Namun, ada beberapa kelemahannya:

• Bagaimana dengan paket node_modules yang digandakan? Ini adalah kelas masalah umum dengan monorepo dan sementara ruang kerja Benang membantu mengangkat, ini bukan solusi monorepo umum. Ada solusi lain, meskipun. Misalnya, PnP Benang menangani ini. Anda juga dapat menggunakan Lerna tanpa Benang dan menggunakan opsi --hoist .
• Bagaimana dengan utilitas menjalankan perintah di seluruh ruang kerja selama pengembangan? Sekali lagi, ruang kerja Benang memungkinkan Anda melakukan ini, tetapi itu tidak berarti seseorang harus menjadikan seluruh monorepo sebagai akar ruang kerja Benang. Membangun perkakas dan skrip yang diperlukan akan berbeda untuk setiap tim dan tergantung pada monorepo mereka. Ruang kerja benang mungkin tidak dirancang sebagai pelari tugas monorepo. Seseorang mungkin mencoba sedikit membengkokkan ruang kerja Yarn untuk melakukan pekerjaan ini (yaitu, menjalankan skrip NPM di seluruh monorepo menggunakan yarn workspace ... ) tetapi penting untuk diingat bahwa satu root ruang kerja untuk seluruh monorepo mungkin tidak akan melakukannya memberi Anda apa yang Anda butuhkan kecuali Anda seperti Babel, Jest, React, dll.

Ada banyak masalah lain yang datang dengan menjalankan monorepo. Misalnya, bagaimana dengan melacak dependensi dan hanya membangun kembali hal-hal yang berubah untuk menghemat waktu di CI? Ruang kerja benang bisa membantu di sana dengan membiarkan Anda menanyakan grafik ketergantungan. Lerna melakukan ini, misalnya, untuk memungkinkan penyortiran topologi dari perintah yang dijalankan. Benang v2 sebenarnya memungkinkan Anda menanyakan grafik ketergantungan juga. Pengelola paket PNPM juga melakukan itu. Tetapi saya berpendapat bahwa tergantung pada kompleksitas monorepo, orang mungkin ingin mencoba alat yang dibuat untuk itu (bukan manajer paket) seperti Bazel , Pants , Buck , dll.

@migueloller Dari persyaratan Anda, saya melihat bahwa Anda tidak memerlukan paket yang sepenuhnya independen atau hal-hal eksotis lainnya, Anda juga ingin menginstal pengembang yang lebih ramping. Dalam kasus seperti itu, Anda harus mulai dengan Benang Monorepo biasa: root tunggal dan semua paket sebagai ruang kerja. Anda akan memiliki waktu instalasi yang lebih cepat, penggunaan disk yang lebih rendah, dan app1 akan menggunakan tautan lokal lib1 dan lib3 . Satu-satunya downside akan lebih sering CI cache invalidation karena penambahan devDep ke lib1 akan memperbarui shared yarn.lock . Tetapi biasanya Anda tidak memperbarui dependensi yang sering terlalu mengkhawatirkan tradeoff ini.

lib1 mungkin bergantung pada lodash@^4.5.0" and lib2 may depend on lodash@^4.10.0". Dalam kasus Monorepo Anda ingin satu versi lodash digunakan, jadi Benang akan menginstal sesuatu yang terbaru yang kompatibel dengan kedua penentu seperti

Ada juga situasi di mana tim independen mengembangkan proyek independen. Dalam hal ini proj1 mungkin ingin tetap di [email protected] dengan proj2 memiliki [email protected] dan memperbaruinya dengan irama mereka sendiri. Tentu saja, Anda dapat mencapai ini dengan menggunakan penentu yang lebih ketat seperti lodash@~4.5.0 , tetapi ini mungkin masih memperbarui ketergantungan tingkat ke-2 terlalu dini. Jadi, secara keseluruhan proyek-proyek itu mungkin sama sekali tidak terkait, kebetulan berada di dalam satu repo git. Dalam hal ini tidak ada alasan untuk mengikatnya sebagai Benang Monorepo dan independensi trade-off untuk file kunci bersama. Perlakukan saja mereka apa adanya: pisahkan proyek dengan kehidupan mandiri mereka. Dan itu disebut Multirepo. Di Unix semua direktori Anda berada di bawah / , tetapi itu tidak berarti bahwa semua proyek JS yang mungkin pada PC Anda harus Monorepo :-)

Membangun image Docker seminimal mungkin untuk penggunaan produksi sama sekali tidak terkait dengan Yarn, tetapi Anda dapat memaksa Yarn untuk menggunakan kembali artefak pengembangan yang disebut yarn.lock dan membantu Anda dengan tugas ini juga.

@the-spyke, dalam contoh ini saya hanya menggunakan 3 ruang kerja tetapi dalam repo kami yang sebenarnya, kami memiliki lebih dari 20 ruang kerja dengan kombinasi perpustakaan dan beban kerja yang digunakan untuk front-end dan back-end. Cara saya melihatnya sekarang adalah bahwa kami memiliki monorepo (atau apa yang Anda sebut multirepo) di mana mungkin masuk akal untuk memiliki beberapa akar ruang kerja Benang dengan file kunci independen. Kami berpikir untuk menggunakan unit yang dapat digunakan sebagai unit pemisahan, ini selaras dengan file kunci.

Saya pikir bagi saya, apa yang membuat ini bekerja dengan sangat baik adalah kenyataan bahwa ruang kerja Benang mendukung jalur di luar root ruang kerja, meskipun posting blog awal mengatakan sebaliknya. Misalnya, Anda dapat memiliki ini:

{
  "workspaces": [
    "../lib1",
    "../lib3"
  ]
}

Kami memiliki kasus penggunaan yang sama dengan @migueloller dan satu ide yang mungkin adalah agar Benang mendukung beberapa set ruang kerja, seperti ini:

{
  "workspaces": {
    "frontend-app": ["frontend", "common"],
    "backend-app": ["backend", "common"]
  }
}

Benang akan mempertahankan dua file kunci tambahan (saya membayangkan yarn.lock akan tetap ada):

.
└── monorepo/
    ├── yarn.frontend-app.lock
    ├── yarn.backend-app.lock
    └── packages/
        ├── frontend
        ├── backend
        └── common

Saat membuat gambar Docker misalnya untuk frontend, kami akan membuat konteks (misalnya, melalui tar ) yang menyertakan ini:

.
└── <Docker build context>/
    ├── yarn.frontend-app.lock
    └── packages/
        ├── frontend
        └── common

Apa yang tidak saya pikirkan secara mendalam adalah apakah mungkin untuk menginstal (tautan di node_modules ) versi dependensi yang tepat jika frontend dan backend mengunci versi yang berbeda. Tapi murni dari tampilan tingkat tinggi, ruang kerja Benang dua dimensi mungkin yang kami cari.

(Sesuatu yang serupa juga diposting di sini .)

Sepertinya Anda tidak memerlukan file kunci per ruang kerja tetapi Anda memerlukan node_modules per ruang kerja untuk penerapan

@gfortaine , jika Anda membaca diskusi, Anda akan menyadari bahwa sebenarnya bukan itu masalahnya. Alasan memiliki lockfile terpisah tidak ada hubungannya dengan instalasi, tetapi memiliki lockfile yang hanya berubah ketika paket tertentu berubah. Lockfile tingkat atas akan berubah dengan perubahan ketergantungan _setiap_ ruang kerja, tetapi lockfile yang dicakup ke satu paket hanya akan berubah ketika dependensi paket _that_ berubah.

Mungkin perlu disebutkan bahwa ini dapat dilakukan di lahan pengguna. Menggunakan paket @yarnpkg/lockfile seseorang dapat mengurai lockfile tingkat atas, dan kemudian menggunakan yarn workspaces info seseorang dapat menentukan dependensi ruang kerja. Dengan menggunakan informasi ini, bersama dengan package.json dari setiap ruang kerja, seseorang dapat membuat file kunci per ruang kerja. Kemudian, seseorang dapat mengaturnya sebagai skrip postinstall di repo untuk menjaga agar masing-masing file kunci tetap sinkron dengan yang tingkat atas.

Saya mungkin mencoba membangun ini dan melaporkan kembali dengan temuan saya.

Sepertinya saya baru saja menemukan implementasi ini meskipun untuk pnpm : @pnpm/make-dedicated-lockfile

Semoga membantu 👍

Kebutuhan saya untuk perilaku ini (versi per ruang kerja, tetapi masih memiliki file kunci di setiap paket) adalah bahwa saya memiliki monorepo bersarang, di mana subpohon diekspor ke repo lain sepenuhnya, jadi harus tetap independen. Saat ini saya terjebak dengan lerna/npm dan beberapa logika khusus untuk mencoba menyamakan versi. Akan lebih baik jika benang (saya kira v2, mengingat di situlah letak dukungan bersarang?) Dapat mengelola semuanya sekaligus, tetapi biarkan subset yang benar dari penyematan global di masing-masing.

Skrip postinstall dapat mencoba mengelola file kunci secara langsung, saya kira. Kedengarannya rumit, tetapi akan menyenangkan.