Hey,

Sometimes I run into an issue that cloning fails because rm didn't remove all files. By that time the source repo is already tagged and commited, and I have to manually delete the tag, the commit and force push to reset it to the original state.

I know I could run the script again with --force, but maybe it would be better if all the task that could fail ran first.

For example in order:

1. bump source repo
2. build source repo
3. clone dist repo to .stage
4. copy dist to .stage
5. bump dist repo
6. commit source, dist repo
7. tag source, dist repo
8. push source, dist repo
9. (publish)

We've been using your tool as a replacement for npm version for some time now, enjoying the additional features such as dry runs and interactivity.

One thing we're missing though is the check to make sure the git working directory is clean before releasing.

Do you think such an opt-in-able check is within the scope of release-it?

Thank you!

Because command line arguments have highest priority, and optimist.boolean initializes all args to false. So all booleans in .release.json that also can be specified on the command line have no effect.

> release-it.cmd minor --dry-run
{ _: [ 'minor' ],
  d: true,
  'dry-run': true,
  e: false,
  debug: false,
  f: false,
  force: false,
  h: false,
  help: false,
  n: false,
  'non-interactive': false,
  p: false,
  publish: false,
  v: false,
  version: false,
  V: false,
  verbose: false,
  '$0': 'node C:\\Users\\necros\\AppData\\Roaming\\npm\\node_modules\\release-it\\bin\\release.js',
  i: 'minor',
  increment: 'minor',
  commitMessage: undefined }

Hi,

I was trying to create github release using release-it but after running release-it without any errors, github release was missing. I tried to find what is going on and I manage to log error response from githubClient.releases.createRelease. I was getting 504 response all the time but without any warnings from release-it. I double check my token and I mange to send a request using Postman REST client. I don't know if this is related but there is new version of github module 1.1.0 and old one is deprecated. I spend some time trying to log what was send to github but I didn't find anything unusually.

{ [Error: 504: Gateway Timeout] defaultMessage: 'Gateway Timeout', message: '504: Gateway Timeout', code: '504' }

I had a question, and potential workflow issue, when using the latest release of release-it programmatically (as compared to v0.0.15).

I tend to setup an npm run-script called build that will lint my node module using jscs and jshint. I also setup a an npm run-script called test to run my Jasmine/Mocha tests. Lastly, I set the buildCommand option to be npm run build && npm run test.

The idea is that linting and unit testing will be executed before the project is tagged and published.

However, it seems the recent version of release-it will, when buildCommand is set, create a dist/ directory. That causes my working directory to include a dist/ directory.

Now, in my case, because the dist/ directory is empty, git will not attempt to add the directory to my index. Furthermore, git will not show the directory when running git status.

Hello dears,

I'm trying to use the 'release-it', with no luck.

When I run release-it -e -V, it shows the following :

_: []
d: false
dry-run: false
e: true
debug: true
f: false
force: false
h: false
help: false
n: false
non-interactive: false
p: false
publish: false
v: false
version: 0.2.16
V: true
verbose: true
$0: release-it
name: SaphirJS.utils
pkgFiles: [ 'package.json' ]
increment: patch
commitMessage: Release %s
tagName: %s
tagAnnotation: Release %s
buildCommand: false
distRepo: false
distStageDir: .stage
distBase: dist
distFiles: [ '**/*' ]
Release source repo
[execute] git rev-parse --git-dir
.git
[execute] bump package.json 0.2.16
WARNING There was a problem bumping the version in package.json
[execute] git add package.json
[execute] git diff-index --name-only HEAD --exit-code
ERROR No changes to release. Use --force to override.
[Error: No changes to release. Use --force to override.]

When I run type bump, it says bash: type: bump: not found.

When I have installed bump using npm install -g bump and run again release-is -e -V with no luck (the same output). When I have run bump package.json 0.2.16, it behaves strangely as it sets the version of my package.json to package.json

 SaphirJS.utils:
 v0.2.15 => vpackage.json
 ↑ bum bum bumped!

Please help.

From time to time, I found myself working on a windows machine. Then I'm like good, feels ready for a release. But then, bam, bug reports enters, CRLF is breaking bin files on Unix systems.

Anyway, I feel it'd be nice if there'd be a safe guard where the release helper automagically convert everything (or only bin files?) to simple LF and prevent eventual problems :)

Github AP v3 support uploading release assets. It will be very useful to upload the release file on every release (JS file, extension file, Executable file,...).

The API should be supported by node-github first: octokit/octokit.js#203
API documentation: https://developer.github.com/v3/repos/releases/#upload-a-release-asset

Here is my release.execute call:

                release.execute({
                    buildCommand:   'npm install && npm run build && npm run ',
                    commitMessage:  'chore(release): v%s',
                    increment:      version,
                    pkgFiles:       'package.json',
                    private:        true,
                    tagAnnotation:  'Release v%s',
                    tagName:        'v%s',
                    verbose:        true
                }).finally(done);
            });

After running release, I am able to publish to git, and as expected I am not prompted to publish to npm. The problem is however, that the task hangs after 'Finished' and I must hit enter to end the procress. This doesnt happen when 'private' is not passed as an argument to execute.

[execute] git tag  --annotate --message="Release v4.0.8" v4.0.8
[?] Push? No
No Git endpoint provided for `distRepo` (distribution repository).
[16:35:27] Finished 'release' after 28 s

From #34 (comment).

When I push a project with version 1.2.3, I have configured my CI to automatically pre-release it as 1.2.4-commithash.0, this is because I use release-it prepatch. I would prefer to create the release, without modifying the patch version, resulting in 1.2.3-commithash.0.

I am using latest version 2.4.3 and always I will get

ERROR Unable to get remote Git url.

What I am doing wrong?

Hi,
I only have package.json in the source repo, and only bower.json in the dist repo. I would like to update both, but with

    "pkgFiles": ["package.json", "bower.json"],

i get

WARNING There was a problem bumping the version in bower.json
ERROR fatal: pathspec 'bower.json' did not match any files

Either it needs to not throw an error if the file is not found, or i would need something like "distPkgFiles". It could also be regex or glob patter. What do u think?

Thx

I like release-it a bit better than the default npm version command since release-it has better support for named prerelease tags like beta, RC, etc. I like to run npm shrinkwrap to freeze my dependency versions and I check in my npm-shrinkwrap.json into GIT.

However, I notice that release-it doesn't update the npm-shrinkwrap.json file like npm version does by default. This makes the package.json and the npm-shrinkwrap.json file out of sync showing different version numbers.

Could you make an update of the npm-shrinkwrap.json version number to match the package.json version number during a release when npm-shrinkwrap.json exists?

Optimist is obsolete and doesn't support default values for booleans. yargs, for example, does. Required to fully fix #22.

require('yargs')
    .boolean('bla')
    .alias('b', 'bla')
    .default('bla', undefined)
    .argv

What would it take to add a step to check that either README or CHANGELOG had something that looked like the latest release version in it, or dropped to $EDITOR to create a changelog message when cutting a release?

Hi, I just installed this module and I got this error on first run (after accepting the tracking prompt). Running npm v2.11.3 and node v0.12.7 on Win7 x64.

C:\Projects\test (master)
λ release-it
? May release-it anonymously report usage statistics to improve the tool over time? Yes
C:\Users\user\AppData\Roaming\npm\node_modules\release-it\node_modules\insight\node_modules\inquirer\node_modules\rx\dist\rx.js:579
    throw e;
          ^
TypeError: undefined is not a function
    at C:\Users\user\AppData\Roaming\npm\node_modules\release-it\lib\tracker.js:36:22
    at Insight.<anonymous> (C:\Users\user\AppData\Roaming\npm\node_modules\release-it\node_modules\insight\lib\index.js:116:3)
    at PromptUI.onCompletion (C:\Users\user\AppData\Roaming\npm\node_modules\release-it\node_modules\insight\node_modules\inquirer\lib\ui\prompt.js:69:10)
    at AnonymousObserver.Rx.AnonymousObserver.AnonymousObserver.completed (C:\Users\user\AppData\Roaming\npm\node_modules\release-it\node_modules\insight\node_modules\inquirer\node_modules\rx\dist\rx.js:1793:12)
    at AnonymousObserver.Rx.internals.AbstractObserver.AbstractObserver.onCompleted (C:\Users\user\AppData\Roaming\npm\node_modules\release-it\node_modules\insight\node_modules\inquirer\node_modules\rx\dist\rx.js:1730:14)
    at AnonymousObserver.tryCatcher (C:\Users\user\AppData\Roaming\npm\node_modules\release-it\node_modules\insight\node_modules\inquirer\node_modules\rx\dist\rx.js:567:29)
    at AutoDetachObserverPrototype.completed (C:\Users\user\AppData\Roaming\npm\node_modules\release-it\node_modules\insight\node_modules\inquirer\node_modules\rx\dist\rx.js:5288:56)
    at AutoDetachObserver.Rx.internals.AbstractObserver.AbstractObserver.onCompleted (C:\Users\user\AppData\Roaming\npm\node_modules\release-it\node_modules\insight\node_modules\inquirer\node_modules\rx\dist\rx.js:1730:14)
    at InnerObserver.onCompleted (C:\Users\user\AppData\Roaming\npm\node_modules\release-it\node_modules\insight\node_modules\inquirer\node_modules\rx\dist\rx.js:3425:65)
    at InnerObserver.tryCatcher (C:\Users\user\AppData\Roaming\npm\node_modules\release-it\node_modules\insight\node_modules\inquirer\node_modules\rx\dist\rx.js:567:29)

Consecutive runs are without this issue.

Hi,

I got this really strange error after updating npm and my other global modules :

$ npm install -g release-it
npm ERR! Windows_NT 6.1.7601
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\xxxxxx\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js" "install" "-g" "release-it"
npm ERR! node v4.2.2
npm ERR! npm  v3.7.3

npm ERR! Invalid Version: 0.0.1alpha1
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     C:\xxxxxxxx\xxxxxxx\xxxxxxxx\xxxxxxx\npm-debug.log





$ npm install -g [email protected]
npm ERR! Windows_NT 6.1.7601
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\xxxxxx\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js" "install" "-g" "[email protected]"
npm ERR! node v4.2.2
npm ERR! npm  v3.7.3

npm ERR! Invalid Version: 0.0.1alpha1
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     C:\xxxxxxxx\xxxxxxx\xxxxxxxx\xxxxxxx\npm-debug.log

An idea about the root cause ?
I cannot install the module anymore ... which makes me very sad ! :)

In my system (Windows 7) release-it does not finish releasing process because the tool hangs on username requesting. Below is console output:

Release source repo
[?] Show updated files? Yes
 M History.md
M  package.json
warning: LF will be replaced by CRLF in package.json.
The file will have its original line endings in your working directory.

[?] Commit (Release version 0.0.4)? Yes
[?] Tag (0.0.4)? Yes
[?] Push? Yes
Username for 'https://github.com':

.release.json for the project is the following:

{
    "commitMessage": "Release version %s",
    "tagAnnotation": "Version %s",
    "publish": true
}

I have a new project where I'm trying to do an initial release. release-it fails on

    "changelogCommand": "git log --pretty=format:'* %s (%h)' [REV_RANGE]",

which resolves to

git log --pretty=format:'* %s (%h)' 0.0.0...HEAD

As far as I can tell, the range it's building is "package.version to HEAD", but in this case, what I have in package.version doesn't represent a valid tag.

To get this out, I had to add a custom "changelogCommand" for my initial release.

    "changelogCommand": "git log --pretty=format:'* %s (%h)'",

For subsequent releases I will be able to reuse the default "changelogCommand".

I don't mind submitting a PR to fix, but my solution wasn't elegant. IE: how would the script know that a tag cannot be found because it's the initial release? Looking for your thoughts @webpro. If nothing else, the documentation can be updated with this gotcha.

Here is the output I get when calling release-it in a git-bash shell on windows:

$ release-it
Release source repo
ERROR Cannot read property 'substring' of undefined

With the command prompt, I get a more expected:

> release-it
Release source repo
? Show updated files? (y/N)

If there is invalid json in .release.json, it is just ignored and default config is used. There should be an error message if the file exists and contains invalid json.

Currently release-it doesn't allow bumping a pre release number.

For example:

Starting version 0.1.0

release-it premajor --dry-run --non-interactive --prereleaseId=rc
[dry-run] bump package.json 1.0.0-rc.0

We've increased the major as expected to 1.0.0 and added the prereleaseId rc.0

If we need to launch another release candidate, currently there is no way for release-it to increase rc.0 to rc.1.

Running pre(major/minor/patch) will update the respective semver version, not the prereleaseId counter.

release-it prepatch --dry-run --non-interactive --prereleaseId=rc
[dry-run] bump package.json 1.0.1-rc.0

This could be solved by adding pre to the list of releaseTypes supported by release-it.

release-it pre --dry-run --non-interactive --prereleaseId=rc
[dry-run] bump package.json 1.0.0-rc.1

@webpro Are there any concerns about including pre as legal releaseTypes?

Would it be possible to prevent the Publish "..." to npm? if the package.json contains "private": true?

$ npm install -g release-it

throws an error:

npm ERR! Error: shasum check failed for /var/folders/ck/nl4qvkv12r3d8gvbkdrn4ngr0000gn/T/npm-53481-W5ngt2fy/registry.npmjs.org/release-it/-/release-it-0.0.8.tgz
npm ERR! Expected: 40339708b08460e888e8635fe4ee99586a5d207d
npm ERR! Actual:   1fcb0a574908a411b21c778a8d25918ae6e825b6

I have tested on node v0.10.26 and v0.11.3.

Hi,

seems that change in commit 6179c5d made it so that the dist repo is not tagged. I understand from the commit message that this is for the case that dist repo is the same as source repo (dunno when does that make sense), however that is not our case - the source and dist repo are different and both should be tagged.

According to the README:

Without a configured distRepo, the package is published to npm.

In my project, N is the default:

[?] Publish "gamepad-plus" to npm? (y/N)

I could be wrong, but it looks like this default should be set to true.

Any reason you are not doing it? I think it would make sense.

In my source repository, I have:

./bower.json
./package.json
./dist/artifact.js

I would like to publish bower.json and artifact.js to the dist repo so it looks like:

bower.json
artifact.js

However, if I use distBase: 'dist', then it will only copy the files that are inside the dist folder. This means that I have to manually update the distributed bower.json when my dependencies change/update, which makes pushing to the dist repo no longer automated.

Perhaps this could be solved by a "copyPkgFiles: true" (however then package.json would get copied as well), or just by stripping distBase off of each of the distFiles like:

var re = new RegExp('^' + distBase);
distFile = distFile.replace(re, '')

This would cause the dist/ to be stripped off of dist/*/, but leave bower.json alone.

Thoughts?

I don't see this in the options, is it possible?

That would be the canonical repo, so would make sense (at least in my case) to use it as "src.pushRepo".

Have you consider using git v1.8.3 git push --follow-tags instead of git push && git push --tags ?

As the tag is annotated, this will prevent for uploading developer unannotated custom tags

--follow-tags

Push all the refs that would be pushed without this option, and also push
annotated tags in refs/tags that are missing from the remote but are pointing
at commit-ish that are reachable from the refs being pushed. This can also
be specified with configuration variable push.followTags. For more information,
see push.followTags in git-config[1].

Would you consider moving the insight setup into the fromCli function so that insight is not started, and user's aren't asked permission, if release-it is used programmatically by other modules?

I would really like to use this project, but I seem to be getting lost. I actually have 2 issues to report, but thought it best to place them here, as they are somewhat related.

1. There seems to be a severe lack of documentation. I can't find any information on what each property in the .release.json file does, how it's used, how to fill it out, etc. I had to start reading the source code to figure out how each property is used -- which was time consuming. It would be great if the docs could be a bit more granular.

2. What I'm really hoping to do is build to a staging folder, like lib/, and then NPM publish from that folder so that lib/ is the "root" folder in the NPM package. It seems like this project could do that, but I've been having a hard time figuring it out (because the lack of docs). At first I thought it would be the dist settings, but that seems to require an external repo. Then I tried src, which then requires settings from dist? It's all rather confusing.

All I'm trying to do is run a "release" command (that builds, versions, and pushes/publishes the project), like so:

• Clean the lib/ folder.
• Run a build command to compile the src/ folder to lib/.
• Run a linter (EXIT if a failure).
• Run tests (EXIT if a failure).
• Copy over package.json (required to be in the lib folder to publish), readmes, and *.md files to the lib/ folder.
• Copy over additional arbitrary files to the lib/ folder. Like ./data/foo/bar.json -> lib/data.json.
• Increment version.
• Publish the lib/ folder (as the root) to NPM.
• Push the changes to git.

I simply want to publish from the lib/ folder so that JS imports can omit the lib/ from the path. For example:

// If published from project root
import Matcher from 'interweave/lib/Matcher';

// When published from lib/
import Matcher from 'interweave/Matcher';

My current release process simply uses NPM/Yarn scripts, but I'm looking for something a bit more robust. https://github.com/milesj/interweave/blob/master/package.json

First of all , thanks a lot for this package, it's saving my life on daily basis.
that said, I want to know if it's possible to access the tag name in some of the release hooks, afterReleaseCommand for example
Thanks in advance

Conventional changelog is a commit convention from angular. I think it is really nice and also very readable for everyone.

There is a node dependency called commitizen where you use git cz instead of git commit, git cz works same like git commit but you go through a command line tool which supports you with writing a conventional commit.

I think it would be very nice to have support for this :)

Greetz

I am getting the following error with an unchanged .release.json file. (I have previously used release-it successfully)

WARNING Probably the current version in package.json is not a known tag in the repository.
ERROR Could not create changelog (0.3.2) to HEAD.

The relevant sections in the .release.json file are as follows:

"commitMessage": "Release v%s",
"tagName": "v%s",
"tagAnnotation": "Release v%s",
"changelogCommand": "git log --pretty=format:'* %s (%h)' [REV_RANGE]",

Hi!

What about integrating prepublish checks from https://github.com/inikulin/publish-please?

Now can't use both, but it will be awesome if every will follow UNIX-way. (one lib for checks, one for publish).

Also see #34 and #35.

I'm failing to understand the use case for dist.repo. The script will push my compiled sources to some repository other than the origin?

I know bower commonly pulls from github. Is that the inspiration?

Could you provide a real-world use case (with examples)? I just want to understand it, so I can see how to properly leverage the functionality in my own project.

First would like to thanks for this convenient tool for speeding up my regular process making releases.

I am using the latest version of release-it, and since 2.5.0 upgraded to [email protected]. Releasing to github is broken due the missing owner parameter for createRelease function. Causing error:

[execute] node-github releases#createRelease myProject
WARNING Bad Request (Attempt 1 of 3)
WARNING Empty value for parameter 'owner': undefined
WARNING Bad Request (Attempt 2 of 3)
WARNING Empty value for parameter 'owner': undefined
ERROR Bad Request (Attempt 3 of 3)
ERROR Empty value for parameter 'owner': undefined

There is a module called mversion that you could use no?

In one of the npm modules I maintain I use a read-only https url for my origin, and push my changes to my own fork.

I do this so I go through the same pull-request flow that any other contributor goes through and I don't accidentally push code that hasn't already went through CI testing directly to the main repository.

Rather than having the release tags pushed to my fork, failing when it tries to push to the read-only origin, or making my origin writable and accidentally pushing commits to it.
It would be nice to have a .release.json option that would make release-it push tags directly to the SSH push url for the main repository.

Hi,

First thanks for this tool which is very useful to maintain my micro libs.

However I found that it always fail on the git push step for me,
I think it should do an explicit "git push origin master" instead of "git push" because that second command is likely to fail for various reason.

For instance if you have other branches (e.g. gh-pages and out of sync, the push will try to push them all and may fails).

Also one of my other library was using the "git://" syntax which doesn't seem to work with this library (or I'm wrong?).

Thanks,

Hi @webpro,

It will be great to support publishing to bower repository.
What do you think ?

++

First some background

We are in the process of introducing proper versioning, including releasing, to our Grunt build. Our Grunt build is producing a common "style guide" - used by various in-house developed applications (both Java and .Net). Mostly I work with Java, and use Maven for build and dependency management. From our Java applications, the "style guide" is embedded using WebJars pulled down from our internal Nexus.
Until now, we have had no proper versioning of the Grunt build (just a hard-coded default version). For versioning and deployment to Nexus, we have a Maven build wrapper around the Grunt build, using standard Maven versioning in the build wrapper (pom.xml).

What we would like to do

We want to establish a common versioning and release process that is satisfactory for all stakeholders in the ""style guide" (both Java and .Net developers). Ideally, we would like to have the versioning and release process defined for Grunt, and get rid of the Maven build wrapper. In the process of investigating how to do this properly, I came accross release-it.

The problem

I have been doing some prototyping, and currently it seems to be impossible to use Maven versioning with release-it. In particular, the notion of a SNAPSHOT version (pre release version) seems hard to achieve.

My wish

Some way to configure release-it to work more or less as the maven-release-plugin when it comes down to versioning and Git commits/tags. I particular:

• Always a SNAPSHOT version in HEAD of branch
• Two commits per release
  • First commit for the release tag
  • Second commit for setting the next development version

Hi.

Maybe a weird usage but I tried this :

$ release-it --verbose --message "Release %s
- improve readme
- add codeclimate badge"

and finally I got this into github as a commit message :

[ '', 'Release %s\n- improve readme\n- add codeclimate badge' ] '0.1.2'

Link : msieurtoph/any-packages@156500d

Not really annoying but if it can be enhanced, it would be cool.

Thx anyway for your package, it makes release process very simple. ;)

We're using npm command line scripts as a build tool for a private project on a private repo in GitHub where it doesn't make sense to release / publish to npm package registry.

Can the options somehow be configured to create a release on the GitHub repository, and not be published to NPM? I wasn't able to grok this just reading the readme file.

Thanks!

It'd be great if you could default the prompts.

For instance I'd like "Publish to NPM?" to default to "Yes"