Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

@picgo/bump-version

Package Overview
Dependencies
Maintainers
3
Versions
6
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@picgo/bump-version

A full `git commit` -> `changelog` -> `release` workflow & convention.

  • 1.0.0
  • Source
  • npm
  • Socket score

Version published
Weekly downloads
58
increased by3.57%
Maintainers
3
Weekly downloads
 
Created
Source

PicGo BumpVersion

A full git commit -> changelog -> release workflow & convention.

It's now only available for Node.js projects. Thanks standard-version for the inspiration.

Installation

npm install -D  @picgo/bump-version conventional-changelog commitizen cz-customizable @commitlint/cli husky

#or

yarn add -D  @picgo/bump-version conventional-changelog commitizen cz-customizable @commitlint/cli husky

alternatively add the following things in your package.json:

"husky": {
  "hooks": {
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
  }
},
"config": {
  "commitizen": {
    "path": "./node_modules/cz-customizable"
  },
  "cz-customizable": {
    "config": "./node_modules/@picgo/bump-version/.cz-config.js"
  },
},
"commitlint": {
  "extends": ["./node_modules/@picgo/bump-verison/commitlint-picgo"]
}

And then add npm run scripts to your package.json:

"scripts": {
  "cz": "git-cz",
  "release": "bump-version"
}

Then you can use npm run cz for commiting valid message && use npm run release to bump version & auto generate changelog in your project!

If you are using yarn, then it will be more simple just like:

# to commit
yarn cz

# to bump version
yarn release

So the workflow is the following:

  1. git add something changed
  2. npm run cz to commit
  3. npm run release to release or deploy

Usage

If you install bump-version in project, then you can just write down the bump-version command in your package.json's scripts field. Then just npm run you-command.

Usage
  bump-version

Example
  bump-version -t major

Options
  -a, --preid-alpha             Prerelease id: alpha. Exp. 1.0.0.alpha-0

  -b, --preid-beta              Prerelease id: beta.  Exp. 1.0.0.beta-0

  -d, --dry                     Run bump version without change anything & output the log in console

  -f, --file                    Read and write the CHANGELOG file, relative to package.json's path
                                Default: CHANGELOG.md

  -p, --path                    A filepath of where your package.json is located
                                Default: ./

  -h, --help                    Display help message

  -t, --type                    Release type. [major, minor, patch, premajor, preminor, prepatch, prerelease]
                                Default: patch

  --push                        Auto push commits to origin master
                                Default: false

  --no-tag                      Tag won't be created
                                Default: tag will be created

  --no-changelog                Changelog won't be created
                                Default: changelog will be created

Don't know which version should be the next? Never mind:

If you reject the default next version, then you can choose which version you want or customize one.

screenshot

if you just want to see what the changelog will be created and nothing will be changed:

npm run release --dry

Badges

Let more people know that you are using PicGo bump-version for elegant workflow!

[![PicGo Convention](https://img.shields.io/badge/picgo-convention-blue.svg?style=flat-square)](https://github.com/PicGo/bump-version)

PicGo Convention

PicGo's commit message guidelines.

Git Commit Message

  • Use the present tense ("add feature" not "added feature")

  • Use the imperative mood ("move cursor to..." not "moves cursor to...")

  • Do not repeat the word in type ("Fix: xxx bugs when..." not "Fix: fix xxx bugs when...")

  • Limit the first line to 72 characters or less

  • Start the commit message with an applicable emoji & type:

    • :sparkles: Feature :sparkles: Feature when adding new features
    • :bug: Fix :bug: Fix when fixing bugs
    • :construction: WIP :construction: WIP when working in progress
    • :hammer: Refactor :hammer: Refactor when changing the code without adding features or fixing bugs
    • :package: Chore :package: Chore when changing the build process or auxiliary tools and libraries such as documentation generation
    • :art: Style :art: Style when improving the format/structure of the code
    • :arrow_up: Upgrade :arrow_up: Upgrade when upgrading dependencies
    • :zap: Perf :zap: Perf when improving performance
    • :pencil: Docs :pencil: Docs when wrting docs
    • :white_check_mark: Test :white_check_mark: Test when adding or updating tests
    • :back: Revert :back: Revert when reverting some commits
    • :pushpin: Init :pushpin: Init when initializing a project
    • :tada: Release :tada: Release when releasing (will be automatically committed by bump-version)
Commit Message Format

A commit message consists of a header, body(optional) and footer(optional). The header has a emoji, type, scope(optional) and subject:

<emoji> <type>([scope]): <subject>
<BLANK LINE>
[body]
<BLANK LINE>
[footer]
Examples
1. Normal

:sparkles: Feature(core): add error notification

:bug: Fix(core): xxx error should be thrown

:sparkles: Feature(core): add error notification

:bug: Fix(core): xxx error should be thrown

and they will be rendered into the following changelog:

# x.x.0 (20xx-xx-xx)

## :sparkles: Features

- add error notification

## :bug: Bug Fixes

- xxx error should be thrown
2. BREAKING CHANGE

Note: BREAKING CHANGE can only be in the type of Feature or Fix.

:sparkles: Feature(core): add error notification

BREAKING CHANGE: change api for error notification

:sparkles: Feature(core): add error notification

BREAKING CHANGE: change api for error notification

and they will be rendered into the following changelog:

# x.x.0 (20xx-xx-xx)

## :sparkles: Features

- add error notification

## BEAKING CHANGES

- change api for error notification

Git Branch Management

Important: Always use rebase or squash or cherry-pick instead of merge

Available branches:

  • master for the release
  • dev for the development
  • alpha for developing the next breaking change or next major release
  • docs or gh-pages for the documentation
  • pr for the pull request [optional]
  • hot-fix for fixing the bug in master [optional]

License

MIT

Copyright (c) 2019 Molunerfinn

FAQs

Package last updated on 09 Apr 2019

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc