Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on my proposal in #249, this PR would allow you to publish a package without also creating a git commit with tag. Since both yarn & npm have a way to disable this behavior through
--no-git-tag-version
I've reused this option name.This is specifically for the scenario where you want to run a CI/CD build that publishes each build to npm, ideally with a timestamp instead of an automatically incrementing build number, i.e.
[email protected]
. This has the benefit of giving other CI/CD packages the ability to consume your unstable npm package while it's going through various stages, (i.e. alpha -> beta -> release) without having to manually maintain and update the package version constraint.Our specific use-case for this is a set-up with separate client and server packages (and teams) that get developed and released simultaneously and would keep
MAJOR.MINOR
synchronized. This approach would allow us to always be working with eachother's latest compatible CI packages in development.Without an option like this each commit would be succeeded by a git-tag commit, effectively doubling the number of commits and creating a lot of noise.
This basically enables the inverse scenario of the current
--no-publish
option (publish to npm, not publish to git).There's one issue: it leaves your git state dirty, as your
package.json
gets modified but never gets committed. In the context of a (containerized) CI build this is not an issue, but I can image that with a persistent repo it will involve a manual clean before doing another publish, or havenp
discard the modifiedpackage.json
if it detects it's running with--no-git-version
.I'm just opening this PR to get the ball rolling, if you decide not to merge this, no worries, I've built my own release that we can use.
Thanks a lot for you work on this lib :)