Standard-version: latest release breaks changelog commit (note, this issue seems to potentially be related to dotgitignore)

[cludden]

error:

$ standard-version
✔ outputting changes to CHANGELOG.md
✔ committing CHANGELOG.md
Command failed: git commit CHANGELOG.md -m "chore(release): 1.0.0"

Command failed: git commit CHANGELOG.md -m "chore(release): 1.0.0"

rolling back to 4.2.0 fixes issue

[bcoe]

git commit CHANGELOG.md -m "chore(release): 1.0.0" looks like a valid command, any chance you could try upgrading again and see if the problem continues -- we might need to add some more debug information.

[bcoe]

@Tapppi @nexdrew @Tapppi, don't suppose any of you have bumped into bugs like this on the latest release? seems to have been working okay on a few of my projects.

[nexdrew]

From the output given in the OP, it looks like you're skipping the "bump" step (because the first line is "outputting changes to CHANGELOG.md" instead of "bumping version in package.json"), which happens if you use a CLI command like standard-version --skip.bump true or if you configure standard-version in your package.json like this:

{
  "standard-version": {
    "skip": {
      "bump": true
    }
  }
}

Since the OP doesn't pass any flags to standard-version, I presume the latter.

In my local testing, I also see this problem when skipping the "bump" step, but I see it when using version 4.2.0 as well. We have this test for skipping "bump" and "changelog" together, which looks like it should fail (via rejected promise) if the test has this problem (and I don't think the test fails), but I run into the failed "git commit CHANGELOG.md" command no matter what else I pass when skipping the "bump" step, so I'm not sure what's going on.

That's all I've found so far. Hopefully this gets us one step closer to the root problem (and solution). In the meantime, @cludden can you please confirm that your package.json is configuring standard-version to skip the "bump" step?

[cludden]

@nexdrew I'm using standard-version as a global npm install, and running as

$ standard-version --release-as major

The package.json from the project that I pasted the output above from does not have a standard-version attribute

[bcoe]

@cludden interesting, perhaps there's a bug related specifically to global behavior; we'll need to dig into this.

[bcoe]

@cludden I believe I see the issue; do you have package.json in your .gitignore? the problem seems to crop up when package.json isn't committed, as a result of us now respecting .gitignore; quite odd.

[matheo]

@bcoe I found a conflict with the Lifecycle scripts, being parsed by git as git-hooks because I was using husky. The "standard-version.precommit" was executed on every commit, and well, that's annoying.
Basically, it's a problem of the .git/hooks/ scripts to detect hooks in the package.json, a shame :(

[cludden]

@bcoe sorry for the late response. package.json is not included in the .gitignore file

[hugomrdias]

i ran into this with just "release": "standard-version", in the package.json and running npm run release

[denouche]

Same problem for me.
In my case the package.json is included in the .gitignore, and the changelog is never outputed with the 4.3.0

[jboothe]

Having same issue with 4.3.0, upgraded to 4.4.0 and still have same issue with:
standard-version --preset angular --release-count 0 "--release-as-patch"
I receive the following error:

Command failed: git commit CHANGELOG.md -m "chore(release): 1.9.7"

Command failed: git commit CHANGELOG.md -m "chore(release): 1.9.7"

Error is outputted twice.
Rolling to 4.2.0 fixed the issue for me as well.

[simonfox]

I just got this issue on 5.0.1.

Using global standard-version install (via yarn) with no package.json config.

We would normally remove the tag prefix via standard-version -t "" and this causes the above. If I run without the prefix flag - standard-version - it works, but it did --skip-bump without it being set .

This is only on a specific project as well - same install works fine on a different project. The project that fails is actually a dotnet project so the project.json is very simple - it has name, version, description, repository, author, license, bugs, homepage properties set. The .gitignore is the default from GitHub for Visual Studio projects.

[bcoe]

@simonfox any chance you could provide a link to a GitHub repo that minimally reproduces this issue? or even better a failing test case. Happy to try to help dig into this, but have been unable to reproduce this issue on any of my own projects.

[simonfox]

OK odd - just copied source of problematic project to a new folder and did git init to start putting a repro together and then tested standard-version -t "" and it worked just fine!

So I dumped the problematic project and re-cloned and all working fine in there as well. Something in .git is somehow messing with standard-version?

cc @bcoe

[simonfox]

@bcoe actually apologies it's definitely acting wierd....this seems to break - https://github.com/simonfox/sv-repro

[bcoe]

@simonfox fascinating, did you potentially have any git hooks configured is a thought?

https://medium.com/the-andela-way/git-hooks-beautifully-automate-tasks-stages-bfb29f42fea1

can we close this potentially?

[simonfox]

@bcoe no hooks configured...does my repro not fail for you?

I've just used repro (linked above ☝️ ) to confirm there is definitely oddness - bump step is skipped for some reason:

[simonfox]

@bcoe ok sorry this seems to be a different issue related to the change to respect .gitignore

Problematic lines are comment lines
https://github.com/simonfox/sv-repro/blob/98333c6d619895c71b45cd275e03cf606b6d5a52/.gitignore#L168
and
https://github.com/simonfox/sv-repro/blob/98333c6d619895c71b45cd275e03cf606b6d5a52/.gitignore#L279

I've traced the issue back the dotgitignore version that standard-version is using. If I update dotgitignore to the very latest commit (currently bafd1e0) it works fine (2.0.1 doesn't work either). Looks like it is the minimatch usage in previous versions that is incorrect.

Hope that helps!

[bcoe]

@simonfox this is a big help, would you mind submitting a patch with the latest version of dotgitignore? I can work on getting a new release out ASAP.

[simonfox]

@bcoe sure can - need latest on dotgitignore to be _released_ first though as current release (2.0) does not solve the issue.

[bcoe]

@simonfox tried to release dotgitignore, interestingly it actually has the bug described in this issue (I think for slightly different reasons than described here); will try to dig into it this weekend.

[bcoe]

@simonfox I've gone ahead and published the newer dotgitignore, I believe it should address the issues you were bumping into.

[simonfox]

@bcoe thanks confirming latest release fixes the issue that I was hitting.

[huchenme]

@bcoe Seems this issue still not resolved in 5.0.2, which contains latest dotgitignore

[bcoe]

@huchenme mind opening a new issue, ideally with a repo that reproduces your issue; hopefully we can figure out the remaining causes.