Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make new version available to postBump scripts #283

Open
debben opened this issue Nov 29, 2018 · 5 comments
Open

Make new version available to postBump scripts #283

debben opened this issue Nov 29, 2018 · 5 comments

Comments

@debben
Copy link

debben commented Nov 29, 2018

I stumbled across standard-version and think it's a great project. The support for bumping versions seems limited to those package formats that use json. I'd like to be able to use this cli tool for packages other than node/bower/composer. I think a low barrier to entry would be to use the postBump script and make the new version available to the script either as an argument or environment variable.

My postBump script could read package/bower/manifest.json etc to get the newly bumped version number, but that assumes my project has one of those files. I'd rather not have to add one just for the purposes of using this tool for managing versions of say a .net nuget package.

@danobot
Copy link

danobot commented Jan 13, 2019

I would like this functionality as well. Surprised it is not supported yet.

@indr
Copy link

indr commented Jun 30, 2019

I would like to add that the $npm_package_version environment variable is not updated. Maybe the bump step could update/export the new version?

@silasb
Copy link

silasb commented Jul 2, 2019

What's interesting is this https://github.com/conventional-changelog/standard-version/blob/master/lib/run-lifecycle-hook.js passes --new-version but I don't think this file is used.

@eraytufan
Copy link

eraytufan commented Jul 22, 2019

Is there any way to get newly calculated version from postbump script? Because $npm_package_version returns the old version not the new one.

@silasb
Copy link

silasb commented Jul 23, 2019

@eraytufan you might want to look at #372 instead. This is probably the path that we'll end up with for custom versioning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

5 participants