prebump script with informational output causes version bump failure

[dmfay]

I have an existing project I'm interested in using with standard-version. The catch is that it has a preversion script which runs JSDoc and commits updated API documentation before release; after going through the standard-version docs, I thought the prebump hook seemed analogous and made the appropriate changes. A dry run showed a proper changelog and the expected bump from 4.4.0 to 4.5.0. However, actually cutting a release did this instead:

✔ Running lifecycle script "prebump"
ℹ - execute command: "sh build/apidocs.sh"
✔ bumping version in package.json from 4.4.0 to null
✔ bumping version in package-lock.json from 4.4.0 to null

It then failed at the tagging step because v4.4.0 already exists. Looking at the code it appears that any output in the prebump script is parsed as a version number, meaning that my original assumption was incorrect and preversion does not map to prebump.

I think at minimum the docs could be clearer about this: the example prebump script echoes a version number, but the language "returns a version #" is a bit unclear in the context of a script and there's nothing indicating that all of stdout is being parsed. I'm actually interested in my script's output so I don't want to pipe everything to /dev/null, and parsing just the last line in prebump seems feasible but kludgey; I think what's called for here is a separate lifecycle event (prerelease maybe?) which would be an actual analogue to preversion and run before prebump.

[bcoe]

@dmfay 👋 sorry for the slow reply; digging myself out of a backlog of 1,000,000 GitHub issues.

I'd love some help figuring out the optimal solution to your issues; be it introducing more docs, perhaps changing the logic around parsing the version # output by prebump (like you suggest). I'm a little hesitant to add more lifecycle scripts, just in the name of keeping things simple ... but I could have my mind changed 😄

[bcoe]

tldr; this sounds like a great first contribution to the project if you're at all interested.

[dmfay]

no worries! The specific task I'm trying to accomplish before cutting a new version is to make sure the automated API docs are up to date. The steps required are:

1. Run JSDoc against a clean working tree
2. Commit the updated API docs
3. Then bump the version, generate the changelog, and so on

preversion is perfect for this since everything happens in isolation. The issue with prebump is that the output of the script is fed in as a version number override. This seems useful to potentially many people who are not me, so I don't think changing the behavior of prebump is the answer. If prebump only took the last line of output as a version number that might work better, but it's still a little surprising and I am not a fan of surprises. That leaves a separate lifecycle event, and if you're good with it I am interested in adding one!

[bcoe]

@dmfay please try npm i standard-version@next it should contain your changes; if things are looking good I'll promote.

[dmfay]

All good -- I released version 4.8.3 with standard-version and the script fired as expected.

[WilcoFiers]

Thanks @dmfay :-)