semantic-release - npm Package Compare versions

Comparing version 4.0.0 to 4.0.1

dist/lib/last-release.js

@@ -15,3 +15,3 @@ 'use strict';
 
-  client.get('' + npm.registry + pkg.name, {
+  client.get('' + npm.registry + pkg.name.replace('/', '%2F'), {
     auth: npm.auth
@@ -18,0 +18,0 @@ }, function (err, data) {

package.json

 {
   "name": "semantic-release",
-  "version": "4.0.0",
   "description": "automated semver compliant package publishing",
@@ -18,2 +17,6 @@ "author": "Stephan Bönnemann <[e-mail]> (http://boennemann.me)",
   ],
+  "engines": {
+    "node": ">0.10",
+    "npm": ">2"
+  },
   "config": {
@@ -94,3 +97,4 @@ "nyc": {
     "test:unit": "nyc tap --no-cov .test/specs/*.js"
-  }
-}
+  },
+  "version": "4.0.1"
+}

README.md

 # semantic-release
-[![Build Status](https://travis-ci.org/semantic-release/semantic-release.svg?branch=next)](https://travis-ci.org/semantic-release/semantic-release)
-[![Coverage Status](https://coveralls.io/repos/semantic-release/semantic-release/badge.svg?branch=next&service=github)](https://coveralls.io/github/semantic-release/semantic-release?branch=next)
-[![Dependency Status](https://david-dm.org/semantic-release/semantic-release/next.svg)](https://david-dm.org/semantic-release/semantic-release/next)
-[![devDependency Status](https://david-dm.org/semantic-release/semantic-release/next/dev-status.svg)](https://david-dm.org/semantic-release/semantic-release/next#info=devDependencies)
-[![js-standard-style](https://img.shields.io/badge/code%20style-standard-brightgreen.svg?style=flat)](https://github.com/feross/standard)
+| [![Build Status](https://travis-ci.org/semantic-release/semantic-release.svg?branch=next)](https://travis-ci.org/semantic-release/semantic-release) | [![Coverage Status](https://coveralls.io/repos/semantic-release/semantic-release/badge.svg?branch=next&service=github)](https://coveralls.io/github/semantic-release/semantic-release?branch=next) | [![Dependency Status](https://david-dm.org/semantic-release/semantic-release/next.svg)](https://david-dm.org/semantic-release/semantic-release/next) | [![devDependency Status](https://david-dm.org/semantic-release/semantic-release/next/dev-status.svg)](https://david-dm.org/semantic-release/semantic-release/next#info=devDependencies) | [![js-standard-style](https://img.shields.io/badge/code%20style-standard-brightgreen.svg?style=flat)](https://github.com/feross/standard) |
+| --- | --- | --- | --- | --- |
 
+`semantic-release` builds upon a set of conventions to give you **fully automated, semver-compliant package publishing**. It's mostly about _commit-messages_, but you can define more _heuristics_.
+
+  | Commands | Comment
+--- | --- | ---
+| **manual** | <pre><code><div>npm version major</div><div>git push origin master --tags</div><div>npm publish</div></code></pre> | You **manually decide** what the **next version** is. You have to remember what major, minor and patch means. You have to remember to push both commits and tags. You have to wait for the CI to pass. |
+| **semantic-release** | <pre><code><div>git commit -m "fix: &lt;message&gt;"</div><div>git push</div></code></pre> | You **think about and describe the changes** you've made. A new version is automatically published with the correct version number.
+
+This removes the immediate connection between human emotions and version numbers, so strictly following the [SemVer](http://semver.org/) spec is not a problem anymore – and that’s ultimately `semantic-release`’s goal.
+
+> ### “We fail to follow SemVer – and why it needn’t matter”
+> #### JSConf Budapest 2015
+
+> [![JSConfBP Talk](https://cloud.githubusercontent.com/assets/908178/8032541/e9bf6300-0dd6-11e5-92c9-8a39211368af.png)](https://www.youtube.com/watch?v=tc2UgG5L7WM&index=6&list=PLFZ5NyC0xHDaaTy6tY9p0C0jd_rRRl5Zm)
+
+> This talk gives you a complete introduction to the underlying concepts of this module
+
+## How does it work?
+
+Instead of writing [meaningless commit messages](http://whatthecommit.com/), we can take our time to think about the changes in the codebase and write them down. Following formalized conventions it this then possible to generate a helpful changelog and to derive the next semantic version number from them.
+
+_Note: This module ships with the [AngularJS Commit Message Conventions](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit) and changelog generator, but you can [define your own](#plugins) style_.
+
+> ### Commit Message Format
+
+> Each commit message consists of a **header**, a **body** and a **footer**.  The header has a special
+format that includes a **type**, a **scope** and a **subject**:
+
+> ```
+<type>(<scope>): <subject>
+<BLANK LINE>
+<body>
+<BLANK LINE>
+<footer>
+```
+
+> [Full explanation](https://github.com/ajoslin/conventional-changelog/blob/master/conventions/angular.md)
+
+When `semantic-release` got setup it will do that after every successful continuous integration build of your master branch (or any other branch you specify) and publish the new version for you. That way no human is directly involved in the release process and your releases are guaranteed to be [unromantic and unsentimental](http://sentimentalversioning.org/).
+
+If you fear the loss of control over timing and marketing implications of software releases you should know that `semantic-release` supports [release channels](https://github.com/npm/npm/issues/2718) using `npm`'s [dist-tags](https://docs.npmjs.com/cli/tag). This way you can keep control over what your users end up using by default, you can decide when to promote an automatically released version to the stable channel and you can choose which versions to write blogposts and tweets about. You can use the same mechanism to support older versions of your software, for example with important security fixes.
+
+This is what happens in series:
+
+| 1. `git push` | 2. `semantic-release pre` | 3. `npm publish` | 4. `semantic-release post` |
+| :--- | :--- | :--- | :---- |
+| New code is pushed and triggers a CI build. | Based on all commits that happened since the last release, the new version number gets written to the `package.json`. | The new version gets published to `npm`. | A changelog gets generated and a [release](https://help.github.com/articles/about-releases/) (including a git tag) on GitHub gets created. |
+
+_Note:_ The current release/tag implementation is tied to GitHub, but could be opened up to Bitbucket, GitLab, et al. Feel free to send PRs for these services.
+
+## Setup
+
 [![NPM](https://nodei.co/npm/semantic-release.png?downloads=true&downloadRank=true&stars=true)](https://nodei.co/npm/semantic-release/)
 
-## What is `semantic-release` about?
+```bash
+npm install -g semantic-release-cli
 
-At its core `semantic-release` is a set of conventions that gives you entirely automated, semver-compliant package publishing. _Coincidentally_ these conventions make sense on their own, like having meaningful commit messages.
+cd your-module
+semantic-release-cli setup
+```
 
-[![JSConfBP Talk](https://cloud.githubusercontent.com/assets/908178/8032541/e9bf6300-0dd6-11e5-92c9-8a39211368af.png)](https://www.youtube.com/watch?v=tc2UgG5L7WM&index=6&list=PLFZ5NyC0xHDaaTy6tY9p0C0jd_rRRl5Zm)
+![dialogue](https://cloud.githubusercontent.com/assets/908178/8766357/f3eadaca-2e34-11e5-8ebb-d40b9ae613d7.png)
 
-> This talk gives you a complete introduction to the underlying concepts
+_[This is what happens under the hood.](https://github.com/semantic-release/cli#manual-setup)_
 
-The next branch is a completely rewritten version of `semantic-release`, that isn't fully tested and documented yet.
-It has lots and lots of great new features, but also breaks a lot of things.
-Unless you're adventurous you should look at the [stable master branch](https://github.com/semantic-release/semantic-release/tree/master).
+## Options
+
+You can pass options either via command line (in [kebab-case](https://lodash.com/docs#kebabCase)) or in the `release` field of your `package.json` (in [camelCase](https://lodash.com/docs#camelCase)). The following two examples are the same, but CLI arguments take precedence.
+
+| CLI | package.json |
+| --- | --- |
+| <pre><code>semantic-release pre --no-debug</code><pre> | <pre><code><div>//package.json</div><div>"release": {</div><div>  "debug": false</div><div>}</div></code></pre><pre><code>semantic-release pre</code></pre> |
+
+
+These options are currently available:
+- `branch`: The branch on which releases should happen. Default: `'master'`
+- `debug`: If true doesn't actually publish to npm or write things to file. Default: `!process.env.CI`
+- `githubToken`: The token used to authenticate with GitHub. Default: `process.env.GH_TOKEN`
+- `githubUrl`: Optional. Pass your GitHub Enterprise endpoint.
+
+_A few notes on `npm` config_:
+1. The `npm` token can only be defined in the environment as `NPM_TOKEN`, because that's where `npm` itself is going to read it from.
+
+2. In order to publish to a different `npm` registry you can just configure that how you would usually do it and `semantic-release` will respect that setting.
+
+3. If you want to use another dist-tag for your publishes than `'latest'` you can specify that inside the `package.json`'s [`publishConfig`](https://docs.npmjs.com/files/package.json#publishconfig) field.
+
+4. `semantic-release` generally tries to orientate itself towards `npm` – it inherits the loglevel for example.
+
+## Plugins
+
+There are four steps where you can customize the `semantic-release` behavior using plugins. A plugin is a regular [option](#options), but inside the `package.json` you can pass additional config.
+
+```json
+{
+  "release": {
+    "analyzeCommits": "npm-module-name",
+    "generateNotes": "./path/to/a/local/module",
+    "verifyConditions": {
+      "path": "./path/to/a/module",
+      "additional": "config"
+    }
+}
+```
+
+```
+semantic-release pre --analyze-commits="npm-module-name"
+```
+
+A plugin itself is an async function that always receives three arguments.
+
+```js
+module.exports = function (pluginConfig, config, callback) {}
+```
+
+- `pluginConfig`: If the user of your plugin specifies additional plugin config in the `package.json` (see the `verifyConditions` example above) then it's this object.
+- `config`: A config object containing a lot of information to act upon.
+  - `env`: All environment variables
+  - `npm`: Select npm configuration bits like `registry`, `tag` and `auth`
+  - `options`: `semantic-release` options like `debug`, or `branch`
+  - `pkg`: Parsed `package.json`
+  - For certain plugins the `config` object contains even more information. See below.
+- `callback`: If an error occurs pass it as first argument. Otherwise pass your result as second argument.
+
+
+### `analyzeCommits`
+
+This plugin is responsible for determining the type of the next release. It additionally receives a `commits` array inside `config`. One commit is an object with a `message` and `hash` property. Call the callback with `'major'`, `'premajor'`, `'minor'`, `'preminor'`, `'patch'`, `'prepatch'`, `'prerelease'`, or `null` if nothing changed. Have a look at the [default implementation](https://github.com/semantic-release/commit-analyzer/).
+
+### `generateNotes`
+
+This plugin is responsible for generating release notes. Call the callback with the notes as a string. Have a look at the [default implementation](https://github.com/semantic-release/release-notes-generator/).
+
+### `verifyConditions`
+
+This plugins is responsible for verifying that a release should happen in the first place. For example, the [default implementation](https://github.com/semantic-release/condition-travis/) verifies that the publish is happening on Travis, that it's the right branch, and that all other build jobs succeeded. There are more use cases for this, e.g. verifying that test coverage is above a certain threshold or that there are no [vulnerabilities](https://nodesecurity.io/) in your dependencies. Be creative.
+
+### `verifyRelease`
+
+This plugin is responsible for verifying a release that was determined before and is about to be published. There is no default implementation. It additionally receives `nextRelease`, `lastRelease` and `commits` inside `config`. While `commits` is the same as with analyzeCommits, `nextRelease` contains a `type` (e.g. `'major'`) and the new version (e.g. `'1.0.0'`) and `lastRelease` contains the old `version`, the `gitHead` at the time of the release and the npm dist-`tag` (e.g. `'latest'`). Using this information you could [detect breaking changes](https://github.com/semantic-release/cracks) or hold back certain types of releases. Again: Be creative.
+
+## ITYM*FAQ*LT
+> I think you might frequently ask questions like these
+
+### Why is the `package.json`'s version not updated in my repository?
+
+The `npm` docs even state:
+
+> The most important things in your package.json are the name and version fields. Those are actually required, and your package won't install without them.
+> – [npm docs](https://docs.npmjs.com/files/package.json#version)
+
+While this entirely true the version number doesn't have to be checked into source control. `semantic-release` takes care of the version field right before `npm publish` uses it – and this is the only point where it _really_ is required.
+
+### Is there a way to preview which version would currently get published?
+
+If you run `npm run semantic-release` locally a dry run gets performed, which logs the version that would currently get published.
+
+### Can I run this on my own machine rather than on a CI server?
+
+Of course you can, but this doesn't necessarily mean you should. Running your tests on an independent machine before releasing software is a crucial part of this workflow. Also it is a pain to set this up locally, with tokens lying around and everything. That said, you can run the scripts with `--debug=false` explicitly. You have to export `GH_TOKEN=<your_token>` and `NPM_TOKEN=<your_other_token>`.
+
+### Can I manually trigger the release of a specific version?
+
+You can trigger a release by pushing to your GitHub repository. You deliberately cannot trigger a _specific_ version release, because this is the whole point of `semantic-release`. Start your packages with `1.0.0` and semver on.  
+
+### Is it _really_ a good idea to release on every push?
+
+It is indeed a great idea because it _forces_ you to follow best practices. If you don't feel comfortable making every passing feature or fix on your master branch addressable via `npm` you might not treat your master right. Have a look at [branch workflows](https://guides.github.com/introduction/flow/index.html). If you still think you should have control over the exact point in time of your release, e.g. because you are following a release schedule, you can release only on the `production`/`deploy`/`release` branch and push your code there in certain intervals, or better yet use [dist-tags](https://docs.npmjs.com/cli/dist-tag).
+
+### Why should I trust `semantic-release` with my releases?
+
+`semantic-release` has a full unit- and integration-test-suite that tests _actual_ `npm` publishes against the [npm-registry-couchapp](https://github.com/npm/npm-registry-couchapp/) on node.js `^0.10`, `^0.12` and io.js `^1`, `^2`. A new version won't get published if it doesn't pass on all these engines.
+
+Note: Currently integration-tests don't run on Travis CI. If you know stuff about npm/Travis/Couch: Please help!
+
+## License
+
+MIT License
+2015 © Stephan Bönnemann and [contributors](https://github.com/semantic-release/semantic-release/graphs/contributors)
+
+![https://twitter.com/trodrigues/status/509301317467373571](https://cloud.githubusercontent.com/assets/908178/6091690/cc86f58c-aeb8-11e4-94cb-15f15f486cde.png)

test/mocks/registry.js

@@ -25,5 +25,5 @@ const nock = require('nock')
   .reply(200, availableModule)
-  .get('/@scoped/available')
+  .get('/@scoped%2Favailable')
   .reply(200, availableModule)
   .get('/unavailable')
   .reply(404, {})

New alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Fixed alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Major refactor

Supply chain risk

Package has recently undergone a major refactor. It may be unstable or indicate significant internal changes. Use caution when updating to versions that include significant changes.

Found 1 instance in 1 package

New author

Supply chain risk

A new npm collaborator published a version of the package for the first time. New collaborators are usually benign additions to a project, but do indicate a change to the security surface area of a package.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

43412

increased by35.85%

Number of lines in readme file

185

increased by780.95%

Number of medium supply chain risk alerts

3

decreased by-40%

No dependency changes