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

grunt-semantic-release

Package Overview
Dependencies
Maintainers
1
Versions
3
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

grunt-semantic-release

release your package without breaking stuff

  • 0.2.1
  • latest
  • npm
  • Socket score

Version published
Maintainers
1
Created
Source

grunt-semantic-release

Build Status Dependency Status devDependency Status

grunt-semantic-release

Using this plugin it is possible to release a new version with just grunt release.

This will

  • ,based on changes made, determine the correct semantic version to release. (Yes the checkboxes are prechecked for you).
  • generate a changelog using conventional-changelog
  • only release code that doesn't fail it's tests.
  • generate the release on TravisCI, rather than on a local, error-prone machine.
  • publish the new version to npm and GitHub Releases.

Here is an example release.

Usage

  • grunt release: suggests correct version
  • grunt release:patch: 0.0.1 => 0.0.2
  • grunt release:minor: 0.0.2 => 0.1.0
  • grunt release:major: 0.1.0 => 1.0.0
  • grunt release --setversion=4.12.3-alpha.19: 1.0.0 => 4.12.3-alpha.19

Getting Started

If you haven't used Grunt before, be sure to check out the Getting Started guide, as it explains how to create a Gruntfile as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:

npm install grunt-semantic-release --save-dev

Once the plugin has been installed, it may be enabled inside your Gruntfile with this line of JavaScript:

grunt.loadNpmTasks('grunt-semantic-release');

Setup

This task comes with a setup script. You should be good to go after running this.

./node_modules/.bin/setup

The "release" task

Overview

In your project's Gruntfile, add a section named release to the data object passed into grunt.initConfig().

Example configuration:

grunt.initConfig({
  release: {
    bump: {
      commitMessage: 'Released v%VERSION%'
    },
    email: 'stephan@boennemann.me',
    name: 'Stephan Bönnemann',
    payload: function(payload, cb) {
      payload.body += '\nvery release'
      payload.body += '\n     such consistent'
      payload.body += '\n  much information'
      payload.body += '\nwow'
      cb(payload);
    }
  }
})

Options

email

Type: Array<String> required

The email used for git commits.

name

Type: Array<String> required

The name used for git commits.

bump

Type: Object optional Default value:

bump: {
  commitMessage: 'chore(release): v%VERSION%',
  files: ['package.json', 'bower.json', 'component.json'],
  commitFiles: ['-a'],
  pushTo: 'origin master'
}

The options object that gets (partly) forwarded to the grunt-bump task.

The task relies on some options for grunt-bump, but there shouldn't be a need to configure this anyways. E.g. when there is a bower.json file present in the file system it is added to the files array automatically.

tasks

Type: Array<String> optional Default value: ['changelog']

A list of tasks that prepare files for the release commit. Per default the changelog is generated here, but you can do other stuff like minifying a distribution build, generating a list of contributors – basically everything you could imagine and find useful.

payload

Type: Function optional

function(payload, cb) {
  getAwesomeContextualGif(function(url) {
    payload.body += '![yo](' + url + ')';
    cb(payload);
  })
}

You can use this function to manipulate the payload for the GitHub release. For example you could search the internet for an amazing gif and append it to the message body.

The payload object already contains information about the repo, owner and tag_name; the body is set to the current changelog.

Caveats

This grunt tasks is extracted from hood.ie's release process and thus tightly coupled to the tools, conventions and needs of hoodie. Extracting this into it's own general purpose task is the first of several steps to make this more universally applicable.

Currently it is required to:

Contributing

In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using Grunt.

License

Copyright (c) 2014 Stephan Bönnemann. Licensed under the MIT license.

Keywords

FAQs

Package last updated on 04 Sep 2014

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