Added support for a --no-git-tag CLI flag that can be used with changeset publish#701
Added support for a --no-git-tag CLI flag that can be used with changeset publish#701
--no-git-tag CLI flag that can be used with changeset publish#701Conversation
…angeset publish`
🦋 Changeset detectedLatest commit: 95210e7 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 95210e7:
|
| // We create the tags after the push above so that we know that HEAD wont change and that pushing | ||
| // wont suffer from a race condition if another merge happens in the mean time (pushing tags wont | ||
| // fail if we are behind the base branch). |
There was a problem hiding this comment.
quite frankly - i have no idea what that comment is about, it might refer to some older implementation
There was a problem hiding this comment.
I think what it's referring to is if you're publishing on every git push, you don't want to create the tags then publish to npm because whether it's published or not is what determines whether it needs to do a publish. (basically replace the the push above with the publish above in the comment)
There was a problem hiding this comment.
Hm, i still dont get it - we query npm info to check if something should be published or not, so creating git tags shouldnt affect this at all
| ` | ||
| Usage | ||
| $ changesets [command] | ||
| $ changeset [command] |
There was a problem hiding this comment.
this kinda showcase how confusing the name of the script is - should we create two executables: changeset and changesets?
| version [--ignore] [--snapshot <?name>] | ||
| publish [--tag <name>] [--otp <code>] [--no-git-tag] | ||
| status [--since <branch>] [--verbose] [--output JSON_FILE.json] |
There was a problem hiding this comment.
I've just unified this a little bit and added stuff that was missing from here
| // mixed type like this is not supported by `meow` | ||
| // if it gets passed explicitly then it's still available on the flags with an inferred type though | ||
| // snapshot: { type: "boolean" | "string" }, |
There was a problem hiding this comment.
i've left this out as a comment since I believe that every supported option should be listed here.
| commit?: boolean; | ||
| changelog?: string; | ||
| access?: AccessType; |
There was a problem hiding this comment.
those were unused and unsupported - probably leftovers from the previous implementation
| ignore?: string | string[]; | ||
| snapshot?: string | boolean; | ||
| tag?: string; | ||
| gitTag?: boolean; |
There was a problem hiding this comment.
I'm not sure about the name of this option. Maybe it should be something like --skip-git-tags?
One thing I've noticed just now is that changeset tag creates git tags, while --tag (accepted by the publish command) is used for npm/release tagging. Can we do better? Should we rename changeset tag to be something else (like changeset git-tag)?
There was a problem hiding this comment.
--no-git-tag seems fine to me
Should we rename changeset tag to be something else (like changeset git-tag)?
I don't think it's that bad but maybe.
2 participants
This should be mostly used together with snapshot releases. They are usually created in the CI environment with custom scripts. So even though the tags were always created there it didn't matter that much because nobody has been pushing them on their own.
However, it feels like for snapshot releases the git tags are rarely what you actually want - and this matters especially if you want to prepare a snapshot machine locally, on your own machine. So to make this use case easier I'm proposing to introduce this flag.
It somewhat feels like a stopgap solution - but since
--snapshotis not used withchangeset publishI don't currently have a better idea to do this. Unless we'd infer the release type from the released package versions - this kinda seems magical though and I'm worried about introducing such a solution prematurely.