npm version --no-git-tag-version --verbose should not log git error

[woppa684]

When npm version is run with both the --no-git-tag-version and --verbose flags, it logs an error if it cannot find a .git folder in the current folder. This error is very annoying for our automated build tooling and seems not relevant in the case that I don't want to update git.

Example of the error:

npm verb version Error: ENOENT: no such file or directory, stat 'C:\some-git-repo\dist\some-folder\.git' npm verb version error checking for .git{[Error: ENOENT: no such file or directory, stat 'C:\some-git-repo\dist\some-folder\.git'] npm verb version stack: npm verb version 'Error: ENOENT: no such file or directory, stat \'C:\\some-git-repo\\dist\\some-folder\\.git\'', npm verb version errno: -4058, npm verb version code: 'ENOENT', npm verb version syscall: 'stat', npm verb version path: 'C:\\some-git-repo\\dist\\some-folder\\.git' } npm verb version not tagging in git 

Expected output:

npm verb version not tagging in git 

This PR just prevents the error from being logged. Of course another option would be to skip the statGitFolder altogether...

[isaacs]

Hm, this bit of code looks a bit odd to me. It probably needs a more thorough review at some point. You're right, it's a bit weird that we stat the git folder in that case just to log a verbose message saying that we're not doing anything with it. It would be good to keep the verbose log, but without the stat, if git-tag-version is turned off. It looks like even when git-tag-version is disabled, we still attempt to commit the change to git, later on in the _commit function.

I'm inclined to punt on this until we have some time to dig deeper into the issue. Would it be terrible to just run without --verbose? Do you need it for other things?

[woppa684]

That's indeed the route we're currently on, but in the mean time we want to be able to track this issue somewhere so that we can point at an issue or PR. I totally agree that this code looks a bit weird (not only my "fix" but _commit as well as you say).

What would be the proper way to make sure that this gets fixed at some point? I could dig a bit deeper myself and make a more complete solution of course.

[isaacs]

We can just leave this open, it's fine. We may decide to take this change (or something like it), but I'd like to have a bit of time to track through the logic and make sure we're not causing other problems. (All too often I've found, when making a seemingly reasonable change in strange-seeming code, the results are strange and unexpected.)