Beranda>Terkait pemrograman>Kode sumber lainnya
Unduh

Versi Standar

standard-version sudah usang . Jika Anda pengguna GitHub, saya sarankan rilis-silakan sebagai alternatif. Jika Anda tidak dapat menggunakan tindakan GitHub, atau jika Anda perlu tetap dengan standard-version untuk beberapa alasan lain, Anda dapat menggunakan garpu komit-dan-tag-versi dari standard-version .

Utilitas untuk versi menggunakan SEMVER dan Generasi Changelog didukung oleh komit konvensional.

Mengalami masalah? Ingin berkontribusi? Bergabunglah dengan kami di Komunitas Penyelenggara Node Slack .

Cara kerjanya:

  1. Ikuti spesifikasi komit konvensional di repositori Anda.
  2. Saat Anda siap untuk dirilis, jalankan standard-version .

standard-version kemudian akan melakukan hal berikut:

  1. Ambil versi repositori Anda saat ini dengan melihat packageFiles [1], jatuh kembali ke git tag terakhir.
  2. bump Versi di bumpFiles [1] berdasarkan komitmen Anda.
  3. Menghasilkan changelog berdasarkan komitmen Anda (menggunakan changelog konvensional di bawah kap).
  4. Membuat commit baru termasuk bumpFiles Anda [1] dan Changelog yang diperbarui.
  5. Membuat tag baru dengan nomor versi baru.

bumpFiles , packageFiles dan updaters

standard-version menggunakan beberapa konsep utama untuk menangani versi menabrak proyek Anda.

  • packageFiles -File yang ditentukan pengguna di mana versi dapat dibaca dan "ditabrak".
    • Contoh: package.json , manifest.json
    • Dalam kebanyakan kasus (termasuk default), packageFiles adalah subset dari bumpFiles .
  • bumpFiles -File yang ditentukan pengguna di mana versi harus "ditabrak", tetapi tidak dibaca secara eksplisit.
    • Contoh: package-lock.json , npm-shrinkwrap.json
  • updaters - Modul sederhana yang digunakan untuk membaca packageFiles dan menulis ke bumpFiles .

Secara default, standard-version mengasumsikan Anda bekerja di proyek berbasis NodeJS ... karena ini, untuk sebagian besar proyek, Anda mungkin tidak perlu berinteraksi dengan opsi-opsi ini.

Yang mengatakan, jika Anda menemukan diri Anda bertanya bagaimana saya bisa menggunakan versi standar untuk file metadata tambahan, bahasa atau file versi? - Opsi konfigurasi ini akan membantu!

Menginstal standard-version

Sebagai skrip npm run Lokal

Instal dan tambahkan ke devDependencies : 

 npm i --save-dev standard-version

Tambahkan skrip npm run ke package.json Anda.json: 

{
  "scripts" : {
    "release" : " standard-version "
  }
}

Sekarang Anda dapat menggunakan npm run release sebagai pengganti npm version .

Ini memiliki manfaat dari membuat repo/paket Anda lebih portabel, sehingga pengembang lain dapat memotong rilis tanpa harus secara global menginstal standard-version pada mesin mereka.

Sebagai bin global

Instal secara global (tambahkan ke PATH Anda): 

 npm i -g standard-version

Sekarang Anda dapat menggunakan standard-version sebagai pengganti npm version .

Ini memiliki manfaat dari memungkinkan Anda menggunakan standard-version pada repo/paket apa pun tanpa menambahkan ketergantungan dev ke masing-masing.

Menggunakan npx

Pada [email protected] , npx diinstal bersama npm . Menggunakan npx Anda dapat menggunakan standard-version tanpa harus menyimpan file package.json dengan menjalankan: npx standard-version .

Metode ini sangat berguna saat menggunakan standard-version dalam proyek non-javascript.

Konfigurasi

Anda dapat mengonfigurasi standard-version baik dengan:

  1. Menempatkan bait standard-version di package.json Anda.json (dengan asumsi proyek Anda adalah JavaScript).
  2. Membuat .versionrc , .versionrc.json atau .versionrc.js .
  • Jika Anda menggunakan .versionrc.js ekspor default Anda harus menjadi objek konfigurasi, atau fungsi yang mengembalikan objek konfigurasi.

Parameter baris perintah apa pun yang diterima dengan standard-version dapat disediakan melalui konfigurasi. Silakan merujuk ke konvensional-changelog-config-spec untuk detail tentang opsi konfigurasi yang tersedia.

Menyesuaikan pembuatan changelog

Secara default (pada 6.0.0 ), standard-version menggunakan preset konvensional.

Preset ini:

  • Menganut secara dekat spesifikasi konvensionalCommits.org.
  • Sangat dapat dikonfigurasi, mengikuti spesifikasi konfigurasi yang dikelola di sini.
    • Kami telah mendokumentasikan pengaturan konfigurasi ini sebagai rekomendasi kepada pembuat perkakas lainnya.

Ada berbagai tombol dan tombol yang dapat Anda tuju terkait dengan generasi Changelog.

Sebagai contoh, misalkan Anda menggunakan GitLab, bukan GitHub, Anda dapat memodifikasi variabel berikut:

  • commitUrlFormat : Format URL dari komitmen yang terdeteksi dalam pesan komit.
  • compareUrlFormat : Format URL yang digunakan untuk membandingkan dua tag.
  • issueUrlFormat : Format URL yang digunakan untuk menautkan ke masalah.

Membuat URL ini cocok dengan format Gitlab, bukan Github.

Penggunaan CLI

Catatan: Untuk meneruskan konfigurasi bersarang ke CLI tanpa mendefinisikannya di package.json menggunakan notasi titik sebagai parameter eg --skip.changelog .

Rilis pertama

Untuk menghasilkan changelog Anda untuk rilis pertama Anda, cukup lakukan: 

 # npm run script
npm run release -- --first-release
# global bin
standard-version --first-release
# npx
npx standard-version --first-release

Ini akan menandai rilis tanpa menabrak versi bumpFiles 1 .

Saat Anda siap, dorong tag git dan npm publish rilis pertama Anda. Hai/

Memotong pelepasan

Jika Anda biasanya menggunakan npm version untuk memotong rilis baru, lakukan ini sebagai gantinya: 

 # npm run script
npm run release
# or global bin
standard-version

Selama pesan komit git Anda konvensional dan akurat, Anda tidak perlu lagi menentukan jenis SEMVER - dan Anda mendapatkan generasi changelog secara gratis! Hai/

Setelah Anda memotong rilis, Anda dapat mendorong tag Git baru dan npm publish (atau npm publish --tag next ) saat Anda siap.

Lepaskan sebagai pra-rilis

Gunakan bendera --prerelease untuk menghasilkan pra-rilis:

Misalkan versi terakhir dari kode Anda adalah 1.0.0 , dan kode Anda yang akan dilakukan telah menambal perubahan. Berlari: 

 # npm run script
npm run release -- --prerelease

Ini akan menandai versi Anda sebagai: 1.0.1-0 .

Jika Anda ingin memberi nama pra-rilis, Anda menentukan nama melalui --prerelease <name> .

Misalnya, misalkan pra-rilis Anda harus berisi awalan alpha : 

 # npm run script
npm run release -- --prerelease alpha

Ini akan menandai versi sebagai: 1.0.1-alpha.0

Rilis sebagai Tipe Target Imperatif ( npm version -LIKE)

Untuk melupakan penggunaan benjolan versi otomatis --release-as dengan argumen major , minor atau patch .

Misalkan versi terakhir dari kode Anda adalah 1.0.0 , Anda hanya akan mendarat fix: berkomitmen, tetapi Anda ingin rilis berikutnya menjadi minor . Cukup jalankan yang berikut: 

 # npm run script
npm run release -- --release-as minor
# Or
npm run release -- --release-as 1.1.0

Anda akan mendapatkan versi 1.1.0 daripada apa yang akan menjadi versi 1.0.1 yang dihasilkan secara otomatis.

Catatan: Anda dapat menggabungkan --release-as dan --prerelease untuk menghasilkan rilis. Ini berguna saat menerbitkan fitur eksperimental.

Mencegah kait git

Jika Anda menggunakan kait git, seperti pra-komit, untuk menguji kode Anda sebelum berkomitmen, Anda dapat mencegah kait dari diverifikasi selama langkah komit dengan lulus opsi --no-verify : 

 # npm run script
npm run release -- --no-verify
# or global bin
standard-version --no-verify

Penandatanganan komit dan tag

Jika Anda memiliki tombol GPG Anda, tambahkan bendera --sign atau -s ke perintah standard-version Anda.

Skrip siklus hidup

standard-version mendukung skrip siklus hidup. Ini memungkinkan Anda untuk menjalankan perintah tambahan Anda sendiri selama rilis. Kait berikut tersedia dan dieksekusi dalam urutan yang didokumentasikan:

  • prerelease : Dieksekusi sebelum sesuatu terjadi. Jika skrip prerelease mengembalikan kode keluar yang tidak nol, versi akan dibatalkan, tetapi tidak memiliki efek lain pada proses tersebut.
  • prebump / postbump : Dieksekusi sebelum dan sesudah versi ditabrak. Jika skrip prebump mengembalikan versi #, itu akan digunakan daripada versi yang dihitung dengan standard-version .
  • prechangelog / postchangelog : Dieksekusi sebelum dan sesudah changelog dihasilkan.
  • precommit / postcommit : Dipanggil sebelum dan sesudah langkah komit.
  • pretag / posttag : Dipanggil sebelum dan sesudah langkah penandaan.

Cukup tambahkan yang berikut ke paket Anda.json untuk mengonfigurasi skrip siklus hidup: 

{
  "standard-version" : {
    "scripts" : {
      "prebump" : " echo 9.9.9 "
    }
  }
}

Sebagai contoh untuk berubah dari menggunakan github untuk melacak item Anda untuk menggunakan proyek Anda Jira menggunakan skrip postchangelog untuk mengganti fragmen url yang berisi 'https://github.com/`myproject`/issues/' dengan tautan ke jira Anda - dengan asumsi Anda telah memasang ganti 

{
  "standard-version" : {
    "scripts" : {
      "postchangelog" : " replace 'https://github.com/myproject/issues/' 'https://myjira/browse/' CHANGELOG.md "
    }
  }
}

Melewatkan langkah siklus hidup

Anda dapat melewatkan salah satu langkah siklus hidup ( bump , changelog , commit , tag ), dengan menambahkan yang berikut ini ke paket Anda.json: 

{
  "standard-version" : {
    "skip" : {
      "changelog" : true
    }
  }
}

Melakukan artefak yang dihasilkan dalam komit rilis

Jika Anda ingin melakukan artefak yang dihasilkan dalam komit rilis, Anda dapat menggunakan bendera --commit-all atau -a . Anda perlu menggelar artefak yang ingin Anda lakukan, sehingga perintah release Anda bisa terlihat seperti ini: 

{
  "standard-version" : {
    "scripts" : {
      "prerelease" : " webpack -p --bail && git add <file(s) to commit> "
    }
  }
}
{
  "scripts" : {
    "release" : " standard-version -a "
  }
}

Mode run kering

Menjalankan standard-version dengan bendera --dry-run memungkinkan Anda untuk melihat perintah apa yang akan dijalankan, tanpa berkomitmen untuk git atau memperbarui file. 

 # npm run script
npm run release -- --dry-run
# or global bin
standard-version --dry-run

Tag awalan

Tag diawali dengan v secara default. Jika Anda ingin mengawali tag Anda dengan hal lain, Anda dapat melakukannya dengan bendera -t . 

standard-version -t @scope/package @

Ini akan mengawali tag Anda agar terlihat seperti @scope/[email protected]

Jika Anda tidak ingin memiliki awalan tag, Anda dapat menggunakan bendera -t dan menyediakannya dengan string kosong sebagai nilai.

Catatan: Cukup -t atau - -Tag -prefix tanpa nilai apa pun akan mundur ke default 'V'

Bantuan CLI 

 # npm run script
npm run release -- --help
# or global bin
standard-version --help

Penggunaan kode 

 const standardVersion = require ( 'standard-version' )

// Options are the same as command line, except camelCase
// standardVersion returns a Promise
standardVersion ( {
  noVerify : true ,
  infile : 'docs/CHANGELOG.md' ,
  silent : true
} ) . then ( ( ) => {
  // standard-version is done
} ) . catch ( err => {
    console . error ( `standard-version failed with message: ${ err . message } ` )
} )

Kiat: Gunakan opsi silent untuk mencegah standard-version dari pencetakan ke console .

FAQ

Bagaimana perbedaan standard-version dari semantic-release ?

semantic-release digambarkan sebagai:

Semantic-Release mengotomatiskan seluruh alur kerja rilis paket termasuk: menentukan nomor versi berikutnya, menghasilkan catatan rilis dan menerbitkan paket.

Sementara keduanya didasarkan pada fondasi yang sama dari pesan komit terstruktur, standard-version mengambil pendekatan yang berbeda dengan menangani versi versi, pembuatan changelog, dan penandaan Git untuk Anda tanpa dorongan otomatis (ke github) atau penerbitan (ke registri NPM). Penggunaan standard-version hanya mempengaruhi repo git lokal Anda - itu tidak mempengaruhi sumber daya jarak jauh sama sekali. Setelah Anda menjalankan standard-version , Anda dapat meninjau keadaan rilis Anda, memperbaiki kesalahan dan mengikuti strategi rilis yang paling masuk akal untuk basis kode Anda.

Kami pikir mereka berdua adalah alat yang fantastis, dan kami mendorong orang untuk menggunakan semantic-release alih-alih standard-version jika masuk akal untuk kasus penggunaan mereka.

Haruskah saya selalu mem -squash berkomitmen saat menggabungkan PR?

Instruksi untuk squash berkomitmen saat menggabungkan permintaan tarik mengasumsikan bahwa satu PR sama dengan, paling banyak, satu fitur atau memperbaiki .

Jika Anda memiliki beberapa fitur atau perbaikan pendaratan dalam satu PR dan setiap komit menggunakan pesan terstruktur, maka Anda dapat melakukan penggabungan standar saat menerima PR. Ini akan melestarikan sejarah komit dari cabang Anda setelah penggabungan.

Meskipun ini akan memungkinkan setiap komit untuk dimasukkan sebagai entri terpisah dalam changelog Anda, entri tidak akan dapat merujuk PR yang menarik perubahan karena pesan komit yang diawetkan tidak termasuk nomor PR.

Untuk alasan ini, kami sarankan menjaga ruang lingkup setiap PR untuk satu fitur umum atau memperbaiki. Dalam praktiknya, ini memungkinkan Anda untuk menggunakan pesan komit yang tidak terstruktur ketika melakukan setiap perubahan kecil dan kemudian menghancurkannya menjadi satu komit dengan pesan terstruktur (merujuk nomor PR) setelah mereka ditinjau dan diterima.

Dapatkah saya menggunakan standard-version untuk file metadata tambahan, bahasa atau file versi?

Pada versi 7.1.0 Anda dapat mengkonfigurasi beberapa bumpFiles dan packageFiles .

  1. Tentukan " filename " bumpFile khusus, ini adalah jalur ke file yang ingin Anda "bump"
  2. Tentukan " updater " bumpFile , ini adalah bagaimana file akan ditabrak. A. Jika Anda menggunakan tipe umum, Anda dapat menggunakan salah satu updaters bawaan standard-version dengan menentukan type . B. Jika Anda menggunakan file versi yang kurang umum, Anda dapat membuat updater sendiri. 
 // .versionrc
{
  "bumpFiles" : [
    {
      "filename" : "MY_VERSION_TRACKER.txt" ,
      // The `plain-text` updater assumes the file contents represents the version.
      "type" : "plain-text"
    } ,
    {
      "filename" : "a/deep/package/dot/json/file/package.json" ,
      // The `json` updater assumes the version is available under a `version` key in the provided JSON document.
      "type" : "json"
    } ,
    {
      "filename" : "VERSION_TRACKER.json" ,
      //  See "Custom `updater`s" for more details.
      "updater" : "standard-version-updater.js"
    }
  ]
}

Jika menggunakan .versionrc.js sebagai file konfigurasi Anda, updater juga dapat ditetapkan sebagai objek, bukan jalur: 

 // .versionrc.js
const tracker = {
  filename : 'VERSION_TRACKER.json' ,
  updater : require ( './path/to/custom-version-updater' )
}

module . exports = {
  bumpFiles : [ tracker ] ,
  packageFiles : [ tracker ]
}

updater kustom s

updater diharapkan menjadi modul JavaScript dengan setidaknya dua metode yang diekspos: readVersion dan writeVersion .

readVersion(contents = string): string

Metode ini digunakan untuk membaca versi dari konten file yang disediakan.

Nilai pengembalian diharapkan menjadi string versi semantik.

writeVersion(contents = string, version: string): string

Metode ini digunakan untuk menulis versi ke konten yang disediakan.

Nilai pengembalian akan ditulis secara langsung (ditimpa) ke file yang disediakan.

Mari kita asumsikan VERSION_TRACKER.json kami memiliki konten berikut: 

{
  "tracker" : {
    "package" : {
      "version" : " 1.0.0 "
    }
  }
}

standard-version-updater.js yang dapat diterima adalah: 

 // standard-version-updater.js
const stringifyPackage = require ( 'stringify-package' )
const detectIndent = require ( 'detect-indent' )
const detectNewline = require ( 'detect-newline' )

module . exports . readVersion = function ( contents ) {
  return JSON . parse ( contents ) . tracker . package . version ;
}

module . exports . writeVersion = function ( contents , version ) {
  const json = JSON . parse ( contents )
  let indent = detectIndent ( contents ) . indent
  let newline = detectNewline ( contents )
  json . tracker . package . version = version
  return stringifyPackage ( json , indent , newline )
}

Lisensi

ISC

Memperluas
Informasi Tambahan
Aplikasi Terkait
Direkomendasikan untuk Anda
Informasi Terkait Semua