standard version 다운로드 - standard version 소스 코드 다운로드

standard version

기타 소스코드

v9.5.0

다운로드

표준 버전

standard-version 더 이상 사용되지 않습니다 . GitHub 사용자라면 릴리스를 대안으로 권장합니다. GitHub 동작을 사용할 수 없거나 다른 이유로 standard-version 고수 해야하는 경우 standard-version 의 커밋 및 태그 버전 포크를 사용할 수 있습니다.

SEMVER 및 기존 커밋으로 구동되는 SEMVER 및 ChangElog 생성을 사용한 버전 작성 유틸리티.

문제가 있습니까? 기여하고 싶습니까? 노드 툴링 커뮤니티 슬랙에 우리와 함께하십시오 .

작동 방식 :

저장소의 기존 커밋 사양을 따르십시오.
출시 준비가되면 standard-version 실행하십시오.

그런 다음 standard-version 다음을 수행합니다.

packageFiles [1]를보고 마지막 git tag 로 다시 떨어지면 현재 저장소의 현재 버전을 검색하십시오.
커밋을 기반으로 bumpFiles [1]의 버전을 bump .
커밋을 기반으로 changelog 생성합니다 (후드 아래에서 기존의 결과를 사용합니다).
bumpFiles [1] 및 업데이트 된 ChangeLog를 포함한 새로운 commit 만듭니다.
새 버전 번호로 새 tag 만듭니다.

`bumpFiles` , `packageFiles` 및 `updaters`

standard-version 프로젝트에서 버전을 처리하기 위해 몇 가지 주요 개념을 사용합니다.

packageFiles 버전을 읽고 "충돌"할 수있는 사용자 정의 파일.
- 예제 : package.json , manifest.json
- 대부분의 경우 (기본값 포함) packageFiles bumpFiles 의 하위 집합입니다.
bumpFiles -버전을 "충돌"해야하지만 명시 적으로 읽지 않는 사용자 정의 파일.
- 예 : package-lock.json , npm-shrinkwrap.json
updaters - packageFiles 읽고 bumpFiles 에 쓰는 데 사용되는 간단한 모듈.

기본적으로 standard-version NodeJS 기반 프로젝트에서 작업하고 있다고 가정합니다.이 때문에 대부분의 프로젝트의 경우 이러한 옵션과 상호 작용할 필요가 없습니다.

즉, 자체가 추가 메타 데이터 파일, 언어 또는 버전 파일에 표준 버전을 어떻게 사용할 수 있습니까? -이 구성 옵션이 도움이됩니다!

`standard-version` 설치

로컬 `npm run` 스크립트로

devDependencies 를 설치하고 추가하십시오.

 npm i --save-dev standard-version

package.json 에 npm run 스크립트를 추가하십시오.

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

이제 npm version 대신 npm run release 사용할 수 있습니다.

이는 리베소/패키지를보다 휴대용으로 만드는 이점이 있으므로 다른 개발자는 컴퓨터에 standard-version 전 세계적으로 설치하지 않고도 릴리스를 줄일 수 있습니다.

글로벌 `bin` 으로

전 세계적으로 설치하십시오 ( PATH 추가) :

 npm i -g standard-version

이제 npm version 대신 standard-version 사용할 수 있습니다.

이는 각각에 DEV 종속성을 추가하지 않고도 모든 리포/패키지에서 standard-version 사용할 수있게하는 이점이 있습니다.

`npx` 사용

[email protected] 기준으로 npx npm 과 함께 설치됩니다. npx 사용하면 NPX standard-version 실행하여 package.json 파일을 유지하지 않고도 npx standard-version 사용할 수 있습니다.

이 방법은 자바 스크립트 프로젝트에서 standard-version 사용할 때 특히 유용합니다.

구성

standard-version 다음과 같이 구성 할 수 있습니다.

package.json 에 standard-version 스탠자를 배치합니다 (프로젝트가 JavaScript라고 가정).
.versionrc , .versionrc.json 또는 .versionrc.js 를 만듭니다.

.versionrc.js 사용하는 경우 기본 내보내기는 구성 객체이거나 구성 객체를 반환하는 함수 여야합니다.

standard-version 으로 허용되는 명령 줄 매개 변수는 대신 구성을 통해 제공 될 수 있습니다. 사용 가능한 구성 옵션에 대한 자세한 내용은 기존 Changelog-Config-Spec을 참조하십시오.

ChangeLog 생성을 사용자 정의합니다

기본적으로 ( 6.0.0 기준), standard-version 기존 커밋 사전 설정을 사용합니다.

이 사전 설정 :

기존 Commits.org 사양에 밀접하게 접착됩니다.
여기에서 유지되는 구성 사양에 따라 구성 가능합니다.
- 이러한 구성 설정을 다른 툴링 제조업체에게 권장 사항으로 문서화했습니다.

ChangeLog 생성과 관련된 다양한 다이얼과 손잡이가 있습니다.

예를 들어, GitHub 대신 Gitlab을 사용하고 있다고 가정하면 다음 변수를 수정할 수 있습니다.

commitUrlFormat : Commit 메시지에서 감지 된 Commit Shas의 URL 형식.
compareUrlFormat : 두 개의 태그를 비교하는 데 사용되는 URL 형식.
issueUrlFormat : 문제에 링크하는 데 사용되는 URL 형식.

이 URL이 Github가 아닌 Gitlab의 형식과 일치합니다.

CLI 사용

참고 : package.json DOT 표기법을 eg --skip.changelog 변수로 사용하여 CLI에 CLI에 중첩 구성을 전달합니다.

첫 번째 릴리스

첫 번째 릴리스에 대한 ChangEleg를 생성하려면 간단히 수행하십시오.

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

버전 bumpFiles 1을 충돌시키지 않고 릴리스를 태그합니다.

준비가되면 GIT 태그를 누르고 npm publish . 영형/

절단 릴리스

일반적으로 npm version 사용하여 새 릴리스를 잘라 내면 대신이 작업을 수행하십시오.

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

GIT 커밋 메시지가 기존적이고 정확한 한 더 이상 Semver 유형을 지정할 필요가 없으며 무료로 ChangElog 생성을받습니다! 영형/

릴리스를 끊은 후에는 새로운 GIT 태그 및 npm publish (또는 npm publish --tag next )를 푸시 할 수 있습니다.

사전 릴리스로 릴리스하십시오

플래그를 사용하여 --prerelease 사용하여 사전 릴리스를 생성하십시오.

코드의 마지막 버전이 1.0.0 이고 커밋 될 코드가 변경되었다고 가정합니다. 달리다:

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

버전을 1.0.1-0 으로 태그합니다.

프리 릴리스의 이름을 지정하려면 --prerelease <name> 통해 이름을 지정합니다.

예를 들어, 사전 릴리스에 alpha 접두사가 포함되어야한다고 가정합니다.

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

이것은 버전에 다음과 같이 태그됩니다. 1.0.1-alpha.0

대상 유형으로 릴리스 ( `npm version` -유사)

major , minor 또는 patch 와 --release-as 자동화 된 버전 범프 사용을 포기합니다.

코드의 마지막 버전이 1.0.0 이라고 가정 해보십시오. 당신은 fix: 만 착륙했지만 다음 릴리스가 minor 되기를 바랍니다. 다음을 간단히 실행합니다.

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

자동 생성 버전 1.0.1 이 아닌 버전 1.1.0 얻게됩니다.

참고 : --release-as 및 --prerelease 결합하여 릴리스를 생성 할 수 있습니다. 이것은 실험 기능을 게시 할 때 유용합니다.

git 후크를 방지하십시오

사전 커밋과 같은 git 후크를 사용하여 커밋하기 전에 코드를 테스트하는 경우 --no-verify 옵션을 전달하여 커밋 단계에서 후크가 검증되는 것을 방지 할 수 있습니다.

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

서명 커밋 및 태그

GPG 키를 설정 한 경우 --sign 또는 -s 플래그를 standard-version 명령에 추가하십시오.

수명주기 스크립트

standard-version 수명주기 스크립트를 지원합니다. 이를 통해 릴리스 중에 자신의 보충 명령을 실행할 수 있습니다. 다음 후크를 사용할 수 있으며 문서화 된 순서대로 실행됩니다.

prerelease : 어떤 일이 일어나기 전에 실행됩니다. prerelease 스크립트가 0이 아닌 출구 코드를 반환하면 버전 설정이 중단되지만 프로세스에는 다른 영향을 미치지 않습니다.
prebump / postbump : 버전이 충돌하기 전후에 실행되었습니다. prebump 스크립트가 버전 #을 반환하면 standard-version 으로 계산 된 버전 대신 사용됩니다.
prechangelog / postchangelog : ChangElog가 생성되기 전후에 실행됩니다.
precommit / postcommit : 커밋 단계 전후에 호출됩니다.
pretag / posttag : 태깅 단계 전후에 호출됩니다.

수명주기 스크립트를 구성하려면 Package.json에 다음을 추가하기 만하면됩니다.

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

예를 들어 Github 사용에서 항목을 추적하여 프로젝트 사용으로 변경하는 예로 Jira는 postchangelog 스크립트를 사용하여 'https://github.com/`myproject`/issues/'가 포함 된 URL 조각을 Jira에 대한 링크로 대체합니다. 이미 설치했다고 가정합니다.

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

수명주기 단계를 건너 뜁니다

Package.json에 다음을 추가하여 수명주기 단계 ( bump , changelog , commit , tag )를 건너 뛸 수 있습니다.

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

릴리스 커밋에서 생성 된 유물을 커밋합니다

릴리스 커밋에서 생성 된 아티팩트를 커밋하려면 --commit-all 또는 -a 플래그를 사용할 수 있습니다. 커밋하고자하는 아티팩트를 무대에 두어야하므로 release 명령은 다음과 같습니다.

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

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

드라이 런 모드

--dry-run 를 사용하여 standard-version 실행하면 git 또는 파일을 업데이트하지 않고 어떤 명령을 실행할 것인지 확인할 수 있습니다.

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

접두사 태그

태그는 기본적으로 v 로 접두사입니다. 태그를 다른 것으로 접두사하려면 -t 플래그로 그렇게 할 수 있습니다.

standard-version -t @scope/package @

@scope/[email protected] 과 같은 것으로 보이도록 태그를 접두사합니다.

태그 접두사를 원하지 않으면 -t 플래그를 사용하여 빈 문자열을 값으로 제공 할 수 있습니다.

참고 : 값이없는 간단히 -t 또는 -tag -prefix는 기본 'V'로 떨어집니다.

CLI 도움

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

코드 사용

 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 } ` )
} )

팁 : silent 옵션을 사용하여 standard-version console 에 인쇄하는 것을 방지하십시오.

FAQ

`standard-version` `semantic-release` 과 어떻게 다릅니 까?

semantic-release 다음과 같이 설명됩니다.

Semantic Release는 다음을 포함하여 전체 패키지 릴리스 워크 플로를 자동화합니다. 다음 버전 번호 결정, 릴리스 노트 생성 및 패키지 게시.

둘 다 구조화 된 커밋 메시지의 동일한 토대를 기반으로하지만 standard-version 자동 푸시 (GitHub) 또는 게시 (NPM 레지스트리) 없이 버전 작성, 변경 사항 생성 및 GIT 태그를 처리함으로써 다른 접근 방식을 취합니다. standard-version 의 사용은 로컬 git repo에만 영향을 미칩니다. 원격 자원에 전혀 영향을 미치지 않습니다. standard-version 실행 한 후에는 릴리스 상태를 검토하고 실수를 올바르게하며 코드베이스에 가장 적합한 릴리스 전략을 따를 수 있습니다.

우리는 그것들이 환상적인 도구라고 생각하며, 사람들이 사용 사례에 적합한 경우 standard-version 대신 semantic-release 사용하도록 권장합니다.

PRS를 병합 할 때 항상 스쿼시가 커밋해야합니까?

풀 요청을 병합 할 때 스쿼시에 대한 지침은 하나의 PR이 최대 하나의 기능 또는 수정과 같다고 가정합니다.

단일 PR에 랜딩을 여러 기능이나 수정하고 각 커밋이 구조화 된 메시지를 사용하는 경우 PR을 수락 할 때 표준 병합을 수행 할 수 있습니다. 이것은 병합 후 지점에서 커밋 기록을 보존합니다.

이로 인해 각 커밋이 변경 사항에 별도의 항목으로 포함될 수 있지만, 보존 된 커밋 메시지에는 PR 번호가 포함되어 있지 않기 때문에 항목은 변경 사항을 초래 한 PR을 참조 할 수 없습니다 .

이러한 이유로 각 PR의 범위를 하나의 일반적인 기능 또는 수정으로 유지하는 것이 좋습니다. 실제로,이를 통해 각 작은 변경을 저지를 때 구조화되지 않은 커밋 메시지를 사용할 수있게 된 다음 검토 및 수락 된 후에 구조화 된 메시지 (PR 번호 참조)로 단일 커밋에 스쿼시 할 수 있습니다.

추가 메타 데이터 파일, 언어 또는 버전 파일에 `standard-version` 사용할 수 있습니까?

버전 7.1.0 기준 여러 bumpFiles 과 packageFiles 구성 할 수 있습니다.

사용자 정의 bumpFile " filename "을 지정하면 "범프"가 원하는 파일의 경로입니다.
bumpFile " updater "를 지정하면 파일이 충돌하는 방법 입니다. 에이. 공통 유형을 사용하는 경우 type 지정하여 standard-version 의 내장 updaters 중 하나를 사용할 수 있습니다. 비. 덜 공통 버전 파일을 사용하는 경우 자신의 updater 만들 수 있습니다.

 // .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"
    }
  ]
}

.versionrc.js 구성 파일로 사용하는 경우 updater 경로가 아닌 객체로 설정 될 수도 있습니다.

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

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

사용자 정의 `updater` s

updater readVersion 및 writeVersion 의 두 가지 방법이 적어도 적어도 JavaScript 모듈 일 것으로 예상됩니다.

`readVersion(contents = string): string`

이 방법은 제공된 파일 내용에서 버전을 읽는 데 사용됩니다.

반환 값은 의미 론적 버전 문자열 일 것으로 예상됩니다.

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

이 방법은 제공된 내용에 버전을 작성하는 데 사용됩니다.

반환 값은 제공된 파일에 직접 (과다 쓰기) 기록됩니다.

VERSION_TRACKER.json 에 다음과 같은 내용이 있다고 가정 해 봅시다.

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

허용되는 standard-version-updater.js 다음과 같습니다.

 // 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 )
}

특허

ISC

확장하다

추가 정보

버전 v9.5.0
유형 기타 소스코드
업데이트 시간 2025-06-03
크기 47.6KB
출처 Github

standard version