Auto: Beberapa Plugin Manajer Paket dalam 1 repo

Memikirkannya sedikit lagi, saya mungkin akan lebih masuk akal untuk memperkenalkan opsi konfigurasi tingkat atas yang baru.

{
  // Still have some global config at root
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  // Plugins used for every package
  "plugins": ["conventional-commits"],
  "packages": [
    // Target specific directories and apply a set of plugins to them
    {
      "target": "www",
      "plugins": ["git-tag"]
    },
    {
      "target": "api",
      "plugins": ["npm"]
    },
    // Specify a pattern or even and array of patterns or directories
    {
      "target": ["packages/**",  "utils"],
      "plugins": ["npm"]
    },
    {
      "target": "web-store",
      "plugins": [
        "chrome-web-store",
        // Whole lifecycle is run for each package so you can have package plugins
        ["upload-assets", { "assets": ["./path/to/file"] }]
      ]
    }
  ]
}

Untuk mencapai ini, saya pikir kita bisa menggunakan fungsi iterator untuk menjalankan shipit pada banyak hal dan menghasilkan jumlah komit yang sama

ex untuk terbaru:

1. menjalankan semua pada waktu yang sama
2. hasil sebelum melakukan changelog
3. komit changelog sekaligus
4. hasil sampai versi menabrak
5. komit versi jika perlu
6. lari sampai akhir

Dengan pengaturan ini Anda benar-benar dapat melewatkan lerna bersama-sama

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    }
  ]
}

Jika tidak ada komit yang cocok dengan package maka tidak ada rilis yang akan dibuat. Ini menyelesaikan manajemen monorepo independen dengan cara yang jauh lebih sederhana dan tanpa lerna . Jika Anda ingin monorepo versi tetap menggunakan rute klasik adalah caranya.

Fitur keren lainnya dari ini adalah Anda dapat memiliki dua proyek leran di repo Anda dengan skema versi yang berbeda ( fixed dan independent )

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "fixed-monorepo",
      "plugins": ["npm"]
    },
    {
      "target": "independent-monorepo",
      "plugins": ["npm"]
    }
  ]
}

Ini berarti Anda dapat menggunakan plugin chrome-web-store plugin npm dalam satu repo.

Saya berasumsi maksud Anda Anda _can't_ menggunakan keduanya dalam proyek yang sama?

Setiap plugin saat ini melakukan, memberi tag, dan mendorong. ini akan membuat banyak kebisingan. mungkin harus memindahkan tindakan git itu ke inti sehingga itu hanya terjadi sekali? meskipun Anda mungkin ingin komit terpisah untuk setiap paket.

Mungkin masuk akal untuk melakukan pendekatan hibrida. Mungkin setiap plugin melakukan, tetapi kami hanya mendorong sekali?

Saya tidak begitu yakin bagaimana tag akan bekerja di dunia di mana setiap folder adalah rilis paketnya sendiri. Apakah Anda membuat tag untuk setiap versi yang Anda buat? Apakah Anda membuat satu di akhir?

Memikirkannya sedikit lagi, saya mungkin akan lebih masuk akal untuk memperkenalkan opsi konfigurasi tingkat atas yang baru.

Saya menyukai gagasan untuk dapat menyesuaikan pengalaman rilis per paket. Pasti dapat melihat beberapa manfaat dari dapat mengelola penyebaran s3/gh-pages untuk paket docs vs. paket perpustakaan Anda.

Satu hal yang harus ditangani adalah penyertaan paket di lebih dari 1 pipa rilis. Apa yang terjadi dalam kasus:

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    },
    {
      "target": "packages/chrome-ext",
      "plugins": ["chrome-web-store"]
    },
  ]
}

Apakah paket chrome-ext dipublikasikan ke npm _dan_ webstore ? Atau apakah rilis npm menang karena dideklarasikan terlebih dahulu?

Saya tidak begitu yakin bagaimana tag akan bekerja di dunia di mana setiap folder adalah rilis paketnya sendiri. Apakah Anda membuat tag untuk setiap versi yang Anda buat? Apakah Anda membuat satu di akhir?

Saya pikir kita bisa menandingi perilaku lerna. hanya banyak tag pada satu komit. setiap tag kemudian menjadi rilisnya sendiri

Apakah paket chrome-ext dipublikasikan ke npm dan toko web? Atau apakah rilis npm menang karena dideklarasikan terlebih dahulu?

Dalam hal ini ya itu akan mencoba melakukan keduanya. Tapi itu hanya konfigurasi yang buruk. Anda dapat menggunakannya sebagai fitur dan mengatakan menerbitkan paket ke dua pendaftar yang berbeda (mis: npm dan github paket registri)

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://npm" }]]
    },
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://github-package-registry" }]]
    },
  ]
}

Ini terdengar menarik... dan rumit

Saya biasanya 👍 dengan konfigurasi yang mencoba menjadi terlalu pintar dengan deteksi (karena itu dapat rusak dengan cara yang tidak terduga dan sulit untuk diuji).

Saya kira pertanyaan pertama saya adalah seperti apa keadaan default ini. Jika Anda hanya memiliki plugin npm , apakah Anda perlu menambahkan konfigurasi sebelum dapat berfungsi? Pertanyaan yang sama dengan yang lain.

Adapun interaksi git, menurut saya seperti interaksi git umumnya hanya menjadi bagian dari pipa plugin. Jika sebuah plugin perlu melakukan komit, itu seharusnya hanya dapat memanfaatkan pengait yang dapat dikomit. Mendorong kemungkinan hanya akan ditangani di inti karena memiliki implikasi pada hal-hal seperti bagaimana CI berjalan.

Jika Anda hanya memiliki plugin npm, apakah Anda perlu menambahkan konfigurasi sebelum berfungsi?

Konfigurasi yang berfungsi hari ini seharusnya berfungsi di dunia packages . Jadi tidak perlu ada perubahan. Sebagian besar perubahan yang melanggar akan menjadi sisi API simpul dan tidak terlihat oleh pengguna normal.

Jika sebuah plugin perlu melakukan komit, itu seharusnya hanya dapat memanfaatkan pengait yang dapat dikomit.

Aku suka ide ini. Memformalkan interaksi git ini dalam otomatis mungkin berguna. Dan jika mereka tidak menggunakan kait ini, itu berarti sedikit lebih banyak suara (mis: komit ekstra dan dorongan ekstra)

Saya juga sedang memikirkan cara menggunakan Auto dengan monorepo dan menemukan pendekatan yang sedikit berbeda yang mungkin sesuai dengan kebutuhan Anda.

Pada dasarnya jika Anda memiliki satu monorepo, Anda dapat memiliki beberapa sub-direktori yang masing-masing memiliki file .autorc yang dapat mengatur plugin apa pun yang dibutuhkan setiap sub proyek.

Anda kemudian dapat memilih untuk memiliki awalan yang berbeda untuk setiap proyek sehingga setiap proyek dapat dirilis pada waktu yang berbeda jika perlu. Misalnya rilis sub-proyek1 dapat ditandai dengan sub-project/v1.4.5 dan proyek lain akan mendapatkan tag sub-project2/v9.9.9

Otomatis kemudian dapat menggunakan sesuatu seperti git describe --tags --matches "sub-project1/*" untuk mendapatkan dan memperbarui tag untuk setiap proyek yang sesuai.

Hanya pemikiran saja.

Itu sebenarnya cukup dekat dengan pendekatan yang saya ambil. saya sudah
telah bekerja pada minggu ini.

Saya harus menambahkan tanda itu ke beberapa perintah sejauh ini (—cocok) dan
sudah berjalan cukup lancar.

Saya telah menggunakan pendekatan bidang "paket" dan pada dasarnya adil dan
array dari "autorc"s

Untuk mendapatkan awalan, saya telah menambahkan pengait untuk plugin untuk memberikan nama. Ini
juga akan membantu memberi sinyal ke otomatis jika plugin kompatibel dengan multi-paket

Pada Rab, Jan 29, 2020 jam 21:11 Alejandro Barrientos <
[email protected]> menulis:

Saya juga berpikir tentang bagaimana menggunakan Auto dengan monorepo dan muncul dengan
pendekatan yang sedikit berbeda yang mungkin sesuai dengan kebutuhan Anda.

Pada dasarnya jika Anda memiliki satu monorepo, Anda dapat memiliki beberapa sub-direktori
bahwa masing-masing memiliki file .autorc sendiri yang dapat mengatur plugin apa pun
setiap sub proyek akan membutuhkan.

Anda kemudian dapat memilih untuk memiliki awalan yang berbeda untuk setiap proyek sehingga
setiap proyek dapat dirilis pada waktu yang berbeda jika perlu. Misalnya
rilis sub-proyek1 dapat ditandai dengan sub-proyek/v1.4.5 dan
proyek lain akan mendapatkan tag sub-project2/v9.9.9

Otomatis kemudian dapat menggunakan sesuatu seperti git explain --tags --matches
"sub-project1/*" untuk mendapatkan dan memperbarui tag untuk setiap proyek yang sesuai.

Hanya pemikiran saja.

—
Anda menerima ini karena Anda yang menulis utas.
Balas email ini secara langsung, lihat di GitHub
https://github.com/intuit/auto/issues/917?email_source=notifications&email_token=AAJDEBGUZR5HF6P3OKRILTDRAJOOXA5CNFSM4KMLWYF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT09
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAJDEBDX72NB5Z7ZJPTDHVLRAJOOXANCNFSM4KMLWYFQ
.

Kembali dan membaca ini lagi, saya sebenarnya cukup bersemangat! Beberapa tag yang diawali dengan nama paket terdengar sangat bagus. Juga, saya sangat menyukai bidang packages .

@hipstersmoothie apakah ada cara mudah hari ini untuk menerbitkan ke 2 pendaftar npm dengan shipit, yang pernah Anda lihat? atau beberapa fitur matikan secara otomatis yang saya tidak memiliki gambaran yang baik saat ini.

@vincentbriglia akankah plugin yang dipublikasikan ke Paket GitHub berfungsi? itu bisa sangat mendukung plugin npm. Akan mudah untuk merilis next dan latest , kenari tidak terlalu masuk akal. Pikiran?

@hipstersmoothie kami memiliki kasus di mana kami menerbitkan paket yang sama ke registri NPM dan registri GHPR. Alasan di sini adalah bahwa GHPR, meskipun diiklankan seperti itu, tidak mem-proxy paket dengan benar. Masalah mendasarnya adalah kami memiliki cakupan yang sama pada npm dan github.

Kami terutama mengembangkan di balik pintu tertutup, kami menggunakan canary build untuk melakukan percakapan/persetujuan dengan tim desain kami dari feature branches > next sehingga canary build masih berguna bagi kami dalam konteks ini. Plugin npm saat ini menyediakan fungsionalitas ini sehingga sayang jika kehilangannya.

Saya kira konteks dengan menggunakan GHPR umumnya adalah lokasi utama untuk menerbitkan dalam konteks "organisasi" pribadi dan jika suatu komponen akan dipublikasikan, npmjs.org adalah yang kedua. (Saya belum pernah melihat orang menginstal komponen publik dari github). Dalam konteks open source, umumnya npmjs, tidak ada GHPR atau registri paket pribadi lainnya.

di samping catatan, karena Anda menyebutkan plugin GHPR tertentu: kami telah menyisihkan waktu untuk minggu depan untuk membuat plugin otomatis yang akan menghapus versi paket berdasarkan beberapa aturan (org dibatasi hingga 50 Gb paket, dan itu termasuk buruh pelabuhan gambar-gambar)

• hapus kenari terakhir dalam jangkauan
• hapus n terakhir berikutnya dalam jangkauan
• ...

Saya juga akan dengan senang hati menunggu Anda membuat penerbit ghpr tertentu sampai pekerjaan dimulai pada v10, ide-ide yang disajikan di sini tampak sangat menarik dan mungkin lebih "bukti masa depan".

kita bisa hidup tanpa mempublikasikan publik dan pribadi pada saat yang sama untuk saat ini, tetapi setidaknya agar Anda tahu ini adalah usecase dari saya.

Saya lebih memikirkan plugin "registri paket sekunder". Jadi plugin npm akan berfungsi sebagaimana adanya, memublikasikan ke registri apa pun yang dikonfigurasi. Kemudian plugin baru ini akan menerbitkan ke registri kedua (apakah itu npm atau ghpr tidak masalah) merilis versi apa pun yang ada di komit HEAD.

di samping catatan, karena Anda menyebutkan plugin GHPR tertentu: kami telah menyisihkan waktu untuk minggu depan untuk membuat plugin otomatis yang akan menghapus versi paket berdasarkan beberapa aturan (org dibatasi hingga 50 Gb paket, dan itu termasuk buruh pelabuhan gambar-gambar)

Ini sepertinya fitur yang bagus. Saya tidak tahu batasan itu ada!

plugin baru ini akan menerbitkan ke registri kedua (apakah itu npm atau ghpr tidak masalah) merilis versi apa pun yang ada di komit HEAD

baik itu pasti akan berhasil! edit: juga untuk skenario kami

Hai! Bagaimana keadaan Auto saat ini sehubungan dengan utas ini? Apakah mungkin untuk menerbitkan lebih dari satu hal dari rilis yang sama?

karena setiap plugin pengelola paket bergantung pada beberapa file tambahan untuk pengelola paket (semua kecuali git-tag )

Saya pikir ini adalah asumsi yang salah. Apakah plugin docker bergantung pada file apa pun? Mungkin tidak perlu untuk itu, jadi mungkin itu contoh yang buruk. Ini satu lagi: Saya tertarik menggunakan Auto dengan sbt (alat build paling umum untuk Scala) dan tidak memiliki konfigurasi JSON/XML yang dapat dibaca mesin. Build sbt dikonfigurasi dengan kode Scala dan untuk mengekstrak informasi apa pun tentang build, Anda perlu berkomunikasi dengan sbt dalam beberapa cara.

Ini menyelesaikan manajemen monorepo independen dengan cara yang jauh lebih sederhana

Tampaknya juga dari utas ini bahwa tujuannya adalah untuk mengakomodasi proyek monorepo dengan beberapa subproyek yang memiliki kebutuhan penerbitan yang berbeda. Bagaimana dengan satu proyek yang menghasilkan berbagai jenis artefak? Misalnya gambar Docker dan arsip konfigurasi (untuk diunggah di suatu tempat). Atau tindakan GitHub yang dapat dipublikasikan sebagai pustaka ke NPM dan sebagai tindakan pada Rilis GitHub.

Setiap plugin saat ini melakukan, memberi tag, dan mendorong. ini akan membuat banyak kebisingan. mungkin harus memindahkan tindakan git itu ke inti sehingga itu hanya terjadi sekali? meskipun Anda mungkin _want_ memisahkan komit untuk setiap package .

Saya pikir ini adalah masalah utama dengan implementasi plugin saat ini. Ini kembali ke kebingungan saya tentang klaim bahwa setiap perintah "hanya melakukan satu hal dengan sangat baik". Menurut pendapat saya kait publish harus benar-benar _hanya mempublikasikan_ untuk manajer paket yang diberikan, bukan membuat komit atau mendorong tag git. Jika setiap plugin penerbitan hanya dapat fokus pada implementasi spesifik manajer paketnya, bagian umum dari proses dapat digunakan kembali dan/atau dibagikan. Apakah masih mungkin untuk mencapai ini dengan Otomatis atau terlalu bias untuk proyek seperti NPM?