Standard-version: How to bump/generate changelog and commit/push in a second time

Created on 22 Feb 2017  路  6Comments  路  Source: conventional-changelog/standard-version

Hello,

I need to embed the version number and the changelog in the generated artifact of my application.

So I would like to be able to bump the version and generate the changelog first, then build my application, then create the commit, tag and push everything.

How to do that with standard-version ?

Thanks in advance for your help

discussion question

Most helpful comment

Yeah you got it right, something like that exactly. I think it might have come time to actually implement it as I can't figure out another solution to your problem.

@stevemao @bcoe @nexdrew Any comments about the configuration / naming for this? Should we start the package.json stanza or use a prenamed script from the scripts section?

I previously threw around a standard-version-pre-commit script in package.json, but I think adding it in e.g. "standard-version"."hook"."pre-commit" might be better..

All 6 comments

Maybe something like this:

standard-version --bump-and-changelog
// let me build my application here
standard-version --commit-and-push --commit-all 

?

Finaly I chose --skip-bump-and-changelog and --skip-commit options.

Let me know what you think about that.

Thanks

Hi, thanks for opening an issue!

There has been discussion about adding a "lifecycle" style hook between the bump and commit phases, but the --commit-all option fixed the use case, as discussed in https://github.com/conventional-changelog/standard-version/issues/96. Using a version number dynamically has been suggested before by @bcoe.

So, a possible fix to your situation would be to:

  1. fetch version number dynamically in artifacts from package.json (if this is not possible, e.g. because package.json isn't included in installations, then this whole thing goes down the drain)
  2. build artifacts before running standard version, e.g.
// package.json
'"prerelease": "webpack -p --bail",
"release": "standard-version --commit-all" // Could replace --commit-all with -a

I see the pull request you created, but what do you think about a lifecycle hook instead, since that forces making the process streamlined, instead of breaking up execution (which might complicate maintenance 馃槩 )?

Thank you for your answer.
I'm totaly ok to use another solution if any can fit my needs, and avoid complicate maintenance

Actually I need to embed into the generated artifact the up to date changelog.

So that's why I suggested to be able to run the process in 2 times:

  • 1: bump and generate the changelog with standard-version --skip-commit
  • let me build my artifact and embed the freshly updated CHANGELOG.md and version number into my artifact (actualy I build my application into a dist/ folder in my project)
  • 2: Commit the bumped package.json, CHANGELOG.md and my dist folder with standard-version --skip-bump-and-changelog --commit-all

About your suggestions:

  • for the first one it's not possible because I build a front-end application with, and only my dist folder is exposed
  • for the second one I think it doesn't help, because building my artifact before running standard-version results to have the last version and changelog into my artifact. But I need the current version and changelog, not the previous one.

About the hook you mentioned, correct me if I didn't understand what you mean, it would be a possibility for me to add some actions (build my artifact for example) between the bump/changelog phase and the commit/tag/push phase? That's it?

It could fits my need I think. How it would be used? A intermediary npm script runned by standard-version between the 2 phases?

"standard-version-postbump": "make build-dist", // let me build my app between the 2 phases

Something like that?

Yeah you got it right, something like that exactly. I think it might have come time to actually implement it as I can't figure out another solution to your problem.

@stevemao @bcoe @nexdrew Any comments about the configuration / naming for this? Should we start the package.json stanza or use a prenamed script from the scripts section?

I previously threw around a standard-version-pre-commit script in package.json, but I think adding it in e.g. "standard-version"."hook"."pre-commit" might be better..

What came of this idea? I see it's still open, but this is my exact use case. I generate a "version.js" file which I add to my src, then build a front end bundle via webpack (or obviously allow others to import via webpack). My solution was a hacked version of standard-version which adds a third input argument which is a "precommit" callback to allow build artifacts to be generated which require the new version number prior to commit. I would much rather have an official option and the lifecycle hooks sounds ideal (wish I'd taken that approach then I'd have a PR instead of this comment).

Was this page helpful?
0 / 5 - 0 ratings