semantic-release 4.3.0 → 4.3.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +98 -49
- package/dist/index.js +13 -2
- package/dist/lib/commits.js +14 -12
- package/dist/lib/get-registry.js +14 -0
- package/package.json +13 -6
- package/test/mocks/child-process.js +1 -0
- package/test/specs/get-registry.js +30 -0
package/README.md
CHANGED
|
@@ -1,43 +1,104 @@
|
|
|
1
|
-
# semantic-release
|
|
1
|
+
# :package::rocket: semantic-release
|
|
2
2
|
|
|
3
|
-
|
|
4
|
-
[](https://coveralls.io/github/semantic-release/semantic-release?branch=master)
|
|
3
|
+
**fully automated package publishing**
|
|
5
4
|
|
|
6
|
-
|
|
7
|
-
|
|
5
|
+
> **Trust us, this will change your workflow for the better.**
|
|
6
|
+
|
|
7
|
+
> – [egghead.io](https://egghead.io/lessons/javascript-how-to-write-a-javascript-library-automating-releases-with-semantic-release)
|
|
8
8
|
|
|
9
9
|
[](https://gitter.im/semantic-release/semantic-release?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
|
|
10
10
|
[](https://github.com/semantic-release/semantic-release)
|
|
11
11
|
[](https://github.com/feross/standard)
|
|
12
|
+
[](http://commitizen.github.io/cz-cli/)
|
|
13
|
+
|
|
14
|
+
[](https://david-dm.org/semantic-release/semantic-release/badger)
|
|
15
|
+
[](https://david-dm.org/semantic-release/semantic-release/badger#info=devDependencies)
|
|
16
|
+
|
|
17
|
+
[](https://travis-ci.org/semantic-release/semantic-release)
|
|
18
|
+
[](https://coveralls.io/github/semantic-release/semantic-release?branch=badger)
|
|
19
|
+
|
|
20
|
+
Out of the box this is just about _commit-messages_, but you can do so much more.
|
|
12
21
|
|
|
13
|
-
|
|
22
|
+
* **Detect breaking changes** using the test suite of your last release: [cracks](https://github.com/semantic-release/cracks)
|
|
23
|
+
* Detect breaking changes using your dependents’ test suites: [Help out! Implement the **dont-break** plugin](https://github.com/semantic-release/semantic-release/issues/65)
|
|
24
|
+
* Detect breaking changes diffing your JSDoc interface: [Help out! Implement the **india** plugin](https://github.com/semantic-release/semantic-release/issues/66)
|
|
25
|
+
* Abort releases with **insufficient test coverage**: [Help out! Implement the **istanbul** plugin](https://github.com/semantic-release/semantic-release/issues/68)
|
|
26
|
+
* Abort releases with **vulnerable dependencies** in the tree: [Help out! Implement the **nsp** plugin](https://github.com/semantic-release/semantic-release/issues/67)
|
|
27
|
+
* Everything you can imagine: [Build Plugins!](https://github.com/semantic-release/semantic-release#plugins)
|
|
14
28
|
|
|
15
29
|
| Commands | Comment
|
|
16
30
|
--- | --- | ---
|
|
17
|
-
| **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. |
|
|
18
|
-
| **semantic-release** | <pre><code><div>git commit -m "fix: <message>"</div><div>git push</div></code></pre> | You **
|
|
31
|
+
| **manual/before** | <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. |
|
|
32
|
+
| **semantic-release/after** | <pre><code><div>git commit -m "fix: <message>"</div><div>git push</div></code></pre> | You **describe the changes** you’ve made. A new version is automatically published with the correct version number.
|
|
33
|
+
|
|
34
|
+
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.
|
|
35
|
+
|
|
36
|
+
<table>
|
|
37
|
+
<tr>
|
|
38
|
+
<th colspan="2">
|
|
39
|
+
“How to Write a JavaScript Library - Automating Releases with semantic-release” – egghead.io
|
|
40
|
+
</th>
|
|
41
|
+
</tr>
|
|
42
|
+
<tr>
|
|
43
|
+
<td colspan="2">
|
|
44
|
+
<a href="https://egghead.io/lessons/javascript-how-to-write-a-javascript-library-automating-releases-with-semantic-release"><img src="https://cloud.githubusercontent.com/assets/908178/9730739/7b1da5d8-5610-11e5-88b6-5c75fdda7ee2.png" alt="egghead.io session"></a>
|
|
45
|
+
</td>
|
|
46
|
+
</tr>
|
|
47
|
+
<tr>
|
|
48
|
+
<td colspan="2">
|
|
49
|
+
A free egghead.io tutorial series on how to write an open source library featuring semantic-release.
|
|
50
|
+
</td>
|
|
51
|
+
</tr>
|
|
52
|
+
<tr>
|
|
53
|
+
<th>
|
|
54
|
+
“We fail to follow SemVer – and why it needn’t matter”
|
|
55
|
+
</th>
|
|
56
|
+
<th>
|
|
57
|
+
“semantic-release Q&A with Kent C. Dodds”
|
|
58
|
+
</th>
|
|
59
|
+
</tr>
|
|
60
|
+
<tr>
|
|
61
|
+
<td>
|
|
62
|
+
<a href="https://www.youtube.com/watch?v=tc2UgG5L7WM&index=6&list=PLFZ5NyC0xHDaaTy6tY9p0C0jd_rRRl5Zm"><img alt="JSConfBP Talk" src="https://cloud.githubusercontent.com/assets/908178/9428178/c337ed26-49a2-11e5-8ad0-a602500a65bf.png"></a>
|
|
63
|
+
</td>
|
|
64
|
+
<td>
|
|
65
|
+
<a href="https://www.youtube.com/watch?v=g6y3DnhkjrI"><img alt="Hangout on Air with Kent C. Dodds" src="https://cloud.githubusercontent.com/assets/908178/9428179/c3387318-49a2-11e5-9f5f-dccd3fbb0c1d.png"></a>
|
|
66
|
+
</td>
|
|
67
|
+
</tr>
|
|
68
|
+
<tr>
|
|
69
|
+
<td>
|
|
70
|
+
This talk gives you a complete introduction to the underlying concepts of this module. 38:30
|
|
71
|
+
</td>
|
|
72
|
+
<td>
|
|
73
|
+
A “Hangouts on Air” conversation with hands on questions and answers about how to use semantic-release. 53:52
|
|
74
|
+
</td>
|
|
75
|
+
</tr>
|
|
76
|
+
</table>
|
|
19
77
|
|
|
20
|
-
|
|
78
|
+
## How does it work?
|
|
21
79
|
|
|
22
|
-
|
|
23
|
-
> #### JSConf Budapest 2015
|
|
80
|
+
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.
|
|
24
81
|
|
|
25
|
-
|
|
82
|
+
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/).
|
|
26
83
|
|
|
27
|
-
|
|
84
|
+
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](https://gist.github.com/boennemann/54042374e49c7ade8910), for example with important security fixes.
|
|
28
85
|
|
|
29
|
-
|
|
86
|
+
This is what happens in series:
|
|
30
87
|
|
|
31
|
-
|
|
88
|
+
| 1. `git push` | 2. `semantic-release pre` | 3. `npm publish` | 4. `semantic-release post` |
|
|
89
|
+
| :--- | :--- | :--- | :---- |
|
|
90
|
+
| 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. |
|
|
32
91
|
|
|
33
|
-
_Note:
|
|
92
|
+
_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.
|
|
34
93
|
|
|
35
|
-
|
|
94
|
+
## Default Commit Message Format
|
|
36
95
|
|
|
37
|
-
|
|
96
|
+
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.
|
|
97
|
+
|
|
98
|
+
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
|
|
38
99
|
format that includes a **type**, a **scope** and a **subject**:
|
|
39
100
|
|
|
40
|
-
|
|
101
|
+
```
|
|
41
102
|
<type>(<scope>): <subject>
|
|
42
103
|
<BLANK LINE>
|
|
43
104
|
<body>
|
|
@@ -45,19 +106,7 @@ format that includes a **type**, a **scope** and a **subject**:
|
|
|
45
106
|
<footer>
|
|
46
107
|
```
|
|
47
108
|
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
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/).
|
|
51
|
-
|
|
52
|
-
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.
|
|
53
|
-
|
|
54
|
-
This is what happens in series:
|
|
55
|
-
|
|
56
|
-
| 1. `git push` | 2. `semantic-release pre` | 3. `npm publish` | 4. `semantic-release post` |
|
|
57
|
-
| :--- | :--- | :--- | :---- |
|
|
58
|
-
| 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. |
|
|
59
|
-
|
|
60
|
-
_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.
|
|
109
|
+
[Full explanation](https://github.com/ajoslin/conventional-changelog/blob/master/conventions/angular.md)
|
|
61
110
|
|
|
62
111
|
## Setup
|
|
63
112
|
|
|
@@ -70,7 +119,7 @@ cd your-module
|
|
|
70
119
|
semantic-release-cli setup
|
|
71
120
|
```
|
|
72
121
|
|
|
73
|
-
|
|
74
123
|
|
|
75
124
|
_[This is what happens under the hood.](https://github.com/semantic-release/cli#manual-setup)_
|
|
76
125
|
|
|
@@ -85,22 +134,22 @@ You can pass options either via command line (in [kebab-case](https://lodash.com
|
|
|
85
134
|
|
|
86
135
|
These options are currently available:
|
|
87
136
|
- `branch`: The branch on which releases should happen. Default: `'master'`
|
|
88
|
-
- `debug`: If true doesn
|
|
137
|
+
- `debug`: If true doesn’t actually publish to npm or write things to file. Default: `!process.env.CI`
|
|
89
138
|
- `githubToken`: The token used to authenticate with GitHub. Default: `process.env.GH_TOKEN`
|
|
90
139
|
- `githubUrl`: Optional. Pass your GitHub Enterprise endpoint.
|
|
91
140
|
|
|
92
141
|
_A few notes on `npm` config_:
|
|
93
|
-
1. The `npm` token can only be defined in the environment as `NPM_TOKEN`, because that
|
|
142
|
+
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.
|
|
94
143
|
|
|
95
|
-
2. In order to publish to a different `npm` registry you can
|
|
144
|
+
2. In order to publish to a different `npm` registry you can specify that inside the `package.json`’s [`publishConfig`](https://docs.npmjs.com/files/package.json#publishconfig) field.
|
|
96
145
|
|
|
97
|
-
3. If you want to use another dist-tag for your publishes than `'latest'` you can specify that inside the `package.json
|
|
146
|
+
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.
|
|
98
147
|
|
|
99
148
|
4. `semantic-release` generally tries to orientate itself towards `npm` – it inherits the loglevel for example.
|
|
100
149
|
|
|
101
150
|
## Plugins
|
|
102
151
|
|
|
103
|
-
There are numerous steps where you can customize `semantic-release
|
|
152
|
+
There are numerous steps where you can customize `semantic-release`’s behaviour using plugins. A plugin is a regular [option](#options), but passed inside the `release` block of `package.json`:
|
|
104
153
|
|
|
105
154
|
```json
|
|
106
155
|
{
|
|
@@ -124,7 +173,7 @@ A plugin itself is an async function that always receives three arguments.
|
|
|
124
173
|
module.exports = function (pluginConfig, config, callback) {}
|
|
125
174
|
```
|
|
126
175
|
|
|
127
|
-
- `pluginConfig`: If the user of your plugin specifies additional plugin config in the `package.json` (see the `verifyConditions` example above) then it
|
|
176
|
+
- `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.
|
|
128
177
|
- `config`: A config object containing a lot of information to act upon.
|
|
129
178
|
- `env`: All environment variables
|
|
130
179
|
- `npm`: Select npm configuration bits like `registry`, `tag` and `auth`
|
|
@@ -144,7 +193,7 @@ This plugin is responsible for generating release notes. Call the callback with
|
|
|
144
193
|
|
|
145
194
|
### `verifyConditions`
|
|
146
195
|
|
|
147
|
-
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
|
|
196
|
+
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.
|
|
148
197
|
|
|
149
198
|
Passing an array of plugins will run them in series.
|
|
150
199
|
|
|
@@ -156,19 +205,19 @@ Passing an array of plugins will run them in series.
|
|
|
156
205
|
|
|
157
206
|
### `getLastRelease`
|
|
158
207
|
|
|
159
|
-
This plugin is responsible for determining a package
|
|
208
|
+
This plugin is responsible for determining a package’s last release version. The [default implementation](https://github.com/semantic-release/last-release-npm) uses the last published version on a npm registry.
|
|
160
209
|
|
|
161
210
|
## ITYM*FAQ*LT
|
|
162
211
|
> I think you might frequently ask questions like these
|
|
163
212
|
|
|
164
|
-
### Why is the `package.json
|
|
213
|
+
### Why is the `package.json`’s version not updated in my repository?
|
|
165
214
|
|
|
166
215
|
The `npm` docs even state:
|
|
167
216
|
|
|
168
|
-
> The most important things in your package.json are the name and version fields. Those are actually required, and your package won
|
|
217
|
+
> 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.
|
|
169
218
|
> – [npm docs](https://docs.npmjs.com/files/package.json#version)
|
|
170
219
|
|
|
171
|
-
While this entirely true the version number doesn
|
|
220
|
+
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.
|
|
172
221
|
|
|
173
222
|
### Is there a way to preview which version would currently get published?
|
|
174
223
|
|
|
@@ -176,7 +225,7 @@ If you run `npm run semantic-release` locally a dry run gets performed, which lo
|
|
|
176
225
|
|
|
177
226
|
### Can I run this on my own machine rather than on a CI server?
|
|
178
227
|
|
|
179
|
-
Of course you can, but this doesn
|
|
228
|
+
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>`.
|
|
180
229
|
|
|
181
230
|
### Can I manually trigger the release of a specific version?
|
|
182
231
|
|
|
@@ -184,13 +233,13 @@ You can trigger a release by pushing to your GitHub repository. You deliberately
|
|
|
184
233
|
|
|
185
234
|
### Is it _really_ a good idea to release on every push?
|
|
186
235
|
|
|
187
|
-
It is indeed a great idea because it _forces_ you to follow best practices. If you don
|
|
236
|
+
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).
|
|
188
237
|
|
|
189
238
|
### Why should I trust `semantic-release` with my releases?
|
|
190
239
|
|
|
191
|
-
`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
|
|
240
|
+
`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.
|
|
192
241
|
|
|
193
|
-
Note: Currently integration-tests don
|
|
242
|
+
Note: Currently integration-tests don’t run on Travis CI. If you know stuff about npm/Travis/Couch: Please help!
|
|
194
243
|
|
|
195
244
|
## Badge
|
|
196
245
|
|
|
@@ -219,4 +268,4 @@ Use this in one of your projects? Include one of these badges in your README.md
|
|
|
219
268
|
MIT License
|
|
220
269
|
2015 © Stephan Bönnemann and [contributors](https://github.com/semantic-release/semantic-release/graphs/contributors)
|
|
221
270
|
|
|
222
|
-
](https://twitter.com/trodrigues/status/509301317467373571)
|
package/dist/index.js
CHANGED
|
@@ -6,6 +6,7 @@ var readFileSync = _require.readFileSync;
|
|
|
6
6
|
var writeFileSync = _require.writeFileSync;
|
|
7
7
|
|
|
8
8
|
var path = require('path');
|
|
9
|
+
var url = require('url');
|
|
9
10
|
|
|
10
11
|
var _ = require('lodash');
|
|
11
12
|
var log = require('npmlog');
|
|
@@ -46,11 +47,12 @@ npmconf.load({}, function (err, conf) {
|
|
|
46
47
|
token: env.NPM_TOKEN
|
|
47
48
|
},
|
|
48
49
|
loglevel: conf.get('loglevel'),
|
|
49
|
-
registry:
|
|
50
|
+
registry: require('./lib/get-registry')(pkg, conf),
|
|
50
51
|
tag: (pkg.publishConfig || {}).tag || conf.get('tag') || 'latest'
|
|
51
52
|
};
|
|
52
53
|
|
|
53
|
-
|
|
54
|
+
// normalize trailing slash
|
|
55
|
+
npm.registry = url.format(url.parse(npm.registry));
|
|
54
56
|
|
|
55
57
|
log.level = npm.loglevel;
|
|
56
58
|
|
|
@@ -116,6 +118,15 @@ npmconf.load({}, function (err, conf) {
|
|
|
116
118
|
process.exit(1);
|
|
117
119
|
}
|
|
118
120
|
|
|
121
|
+
try {
|
|
122
|
+
var shrinkwrap = JSON.parse(readFileSync('./npm-shrinkwrap.json'));
|
|
123
|
+
shrinkwrap.version = release.version;
|
|
124
|
+
writeFileSync('./npm-shrinkwrap.json', JSON.stringify(shrinkwrap, null, 2));
|
|
125
|
+
log.verbose('pre', 'Wrote version ' + release.version + ' to npm-shrinkwrap.json.');
|
|
126
|
+
} catch (e) {
|
|
127
|
+
log.silly('pre', 'Couldn\'t find npm-shrinkwrap.json.');
|
|
128
|
+
}
|
|
129
|
+
|
|
119
130
|
writeFileSync('./package.json', JSON.stringify(_.assign(pkg, {
|
|
120
131
|
version: release.version
|
|
121
132
|
}), null, 2));
|
package/dist/lib/commits.js
CHANGED
|
@@ -19,21 +19,23 @@ module.exports = function (_ref, cb) {
|
|
|
19
19
|
if (!from) return extract();
|
|
20
20
|
|
|
21
21
|
exec('git branch --contains ' + from, function (err, stdout) {
|
|
22
|
-
if (err) return cb(err);
|
|
23
22
|
var inHistory = false;
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
23
|
+
var branches = undefined;
|
|
24
|
+
|
|
25
|
+
if (!err && stdout) {
|
|
26
|
+
branches = stdout.split('\n').map(function (result) {
|
|
27
|
+
if (branch === result.replace('*', '').trim()) {
|
|
28
|
+
inHistory = true;
|
|
29
|
+
return null;
|
|
30
|
+
}
|
|
31
|
+
return result.trim();
|
|
32
|
+
}).filter(function (branch) {
|
|
33
|
+
return !!branch;
|
|
34
|
+
});
|
|
35
|
+
}
|
|
34
36
|
|
|
35
37
|
if (!inHistory) {
|
|
36
|
-
log.error('commits', 'The commit the last release of this package was derived from is
|
|
38
|
+
log.error('commits', 'The commit the last release of this package was derived from is not in the direct history of the "' + branch + '" branch.\nThis means semantic-release can not extract the commits between now and then.\nThis is usually caused by force pushing, releasing from an unrelated branch, or using an already existing package name.\nYou can recover from this error by publishing manually or restoring the commit "' + from + '".' + (branches && branches.length ? '\nHere is a list of branches that still contain the commit in question: \n * ' + branches.join('\n * ') : ''));
|
|
37
39
|
return cb(new SemanticReleaseError('Commit not in history', 'ENOTINHISTORY'));
|
|
38
40
|
}
|
|
39
41
|
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
'use strict';
|
|
2
|
+
|
|
3
|
+
module.exports = function (pkg, conf) {
|
|
4
|
+
if (pkg.publishConfig && pkg.publishConfig.registry) return pkg.publishConfig.registry;
|
|
5
|
+
|
|
6
|
+
if (pkg.name[0] !== '@') return conf.get('registry') || 'https://registry.npmjs.org/';
|
|
7
|
+
|
|
8
|
+
var scope = pkg.name.split('/')[0];
|
|
9
|
+
var scopedRegistry = conf.get(scope + '/registry');
|
|
10
|
+
|
|
11
|
+
if (scopedRegistry) return scopedRegistry;
|
|
12
|
+
|
|
13
|
+
return conf.get('registry') || 'https://registry.npmjs.org/';
|
|
14
|
+
};
|
package/package.json
CHANGED
|
@@ -8,10 +8,6 @@
|
|
|
8
8
|
"bugs": {
|
|
9
9
|
"url": "https://github.com/semantic-release/semantic-release/issues"
|
|
10
10
|
},
|
|
11
|
-
"engines": {
|
|
12
|
-
"node": ">=0.10",
|
|
13
|
-
"npm": ">=2"
|
|
14
|
-
},
|
|
15
11
|
"config": {
|
|
16
12
|
"nyc": {
|
|
17
13
|
"exclude": [
|
|
@@ -20,9 +16,12 @@
|
|
|
20
16
|
]
|
|
21
17
|
}
|
|
22
18
|
},
|
|
19
|
+
"czConfig": {
|
|
20
|
+
"path": "node_modules/cz-conventional-changelog/"
|
|
21
|
+
},
|
|
23
22
|
"dependencies": {
|
|
24
23
|
"@semantic-release/commit-analyzer": "^2.0.0",
|
|
25
|
-
"@semantic-release/condition-travis": "^4.
|
|
24
|
+
"@semantic-release/condition-travis": "^4.1.2",
|
|
26
25
|
"@semantic-release/error": "^1.0.0",
|
|
27
26
|
"@semantic-release/last-release-npm": "^1.2.1",
|
|
28
27
|
"@semantic-release/release-notes-generator": "^2.0.0",
|
|
@@ -42,6 +41,7 @@
|
|
|
42
41
|
"devDependencies": {
|
|
43
42
|
"babel": "^5.5.8",
|
|
44
43
|
"coveralls": "^2.11.2",
|
|
44
|
+
"cz-conventional-changelog": "^1.1.0",
|
|
45
45
|
"mkdirp": "^0.5.1",
|
|
46
46
|
"nixt": "^0.4.1",
|
|
47
47
|
"nock": "^2.5.0",
|
|
@@ -52,6 +52,10 @@
|
|
|
52
52
|
"standard": "^5.0.2",
|
|
53
53
|
"tap": "^1.3.1"
|
|
54
54
|
},
|
|
55
|
+
"engines": {
|
|
56
|
+
"node": ">=0.10",
|
|
57
|
+
"npm": ">=2"
|
|
58
|
+
},
|
|
55
59
|
"homepage": "https://github.com/semantic-release/semantic-release/tree/next#readme",
|
|
56
60
|
"keywords": [
|
|
57
61
|
"author",
|
|
@@ -70,6 +74,9 @@
|
|
|
70
74
|
"type": "git",
|
|
71
75
|
"url": "git+https://github.com/semantic-release/semantic-release.git"
|
|
72
76
|
},
|
|
77
|
+
"release": {
|
|
78
|
+
"branch": "badger"
|
|
79
|
+
},
|
|
73
80
|
"scripts": {
|
|
74
81
|
"build": "rimraf dist && mkdirp dist && babel src --out-dir dist",
|
|
75
82
|
"coverage": "nyc report",
|
|
@@ -84,5 +91,5 @@
|
|
|
84
91
|
"test:style": "standard",
|
|
85
92
|
"test:unit": "nyc tap --no-cov .test/specs/*.js"
|
|
86
93
|
},
|
|
87
|
-
"version": "4.3.
|
|
94
|
+
"version": "4.3.5"
|
|
88
95
|
}
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
const test = require('tap').test
|
|
2
|
+
|
|
3
|
+
const getRegistry = require('../../dist/lib/get-registry')
|
|
4
|
+
|
|
5
|
+
test('get correct registry', (t) => {
|
|
6
|
+
t.is(getRegistry({
|
|
7
|
+
name: 'publish-config',
|
|
8
|
+
publishConfig: {
|
|
9
|
+
registry: 'a'
|
|
10
|
+
}},
|
|
11
|
+
{}), 'a')
|
|
12
|
+
|
|
13
|
+
t.is(getRegistry({name: 'normal'}, {get: () => 'b'}), 'b')
|
|
14
|
+
|
|
15
|
+
t.is(getRegistry({name: 'normal'}, {get: () => null}), 'https://registry.npmjs.org/')
|
|
16
|
+
|
|
17
|
+
t.is(getRegistry({name: '@scoped/foo'}, {
|
|
18
|
+
get: (input) => input === '@scoped/registry' ? 'c' : 'd'
|
|
19
|
+
}), 'c')
|
|
20
|
+
|
|
21
|
+
t.is(getRegistry({name: '@scoped/bar'}, {
|
|
22
|
+
get: () => 'e'
|
|
23
|
+
}), 'e')
|
|
24
|
+
|
|
25
|
+
t.is(getRegistry({name: '@scoped/baz'}, {
|
|
26
|
+
get: () => null
|
|
27
|
+
}), 'https://registry.npmjs.org/')
|
|
28
|
+
|
|
29
|
+
t.end()
|
|
30
|
+
})
|