Repository navigation
pre mode with "latest" dist-tag publishing? #786
Description
Hey everyone! Fred from Astro here, and we've just entered a 2-month v1.0.0-beta.X period before our official Astro v1.0 release in June.
We've been happy changeset users so far but now I'm not sure the best way to structure/configure changesets for the next two months. What I'd really want is...
What we want:
- Every package in the monorepo released to
latest - Only
astrois versioned atv1.0.0-beta.X, all others follow v0.x semver - don't need to be in
premode if we can help it.
What we've tried:
But I don't think that's possible. Based on what I know of changesets, I expected this to work as a secondary option:
- monorepo is in
premode (tag: 'beta') - when we publish, we can still publish all packages to
latest
The problem is that changeset publish --tag latest doesn't seem to be respected. When I run a dry-run, I see an error that --tag isn't supported in pre mode.
Any thoughts for how we could achieve something like this with changesets? Since it's short term, I'm willing to do something hacky if you have any suggestions. Thank you!
Activity
Andarist commentedon Apr 5, 2022
What should be the tag for the astro? Should it be
betahere? Should theastro@latestkeep pointing to some older0.xversion?Even if this would work... what would happen to
astro?changeset publishtries to publish everything that has not yet been published to the registry. And it seems that you want to avoid publishingastrobeta versions as latest (unless I misunderstood the issue).If this would help you - I'm open to scheduling a quick call to hash it out cause I think there is definitely some workaround (even if slightly hacky :P) to make it work for you. I just need to understand all of your constraints/requirements properly
diegohaz commentedon Apr 7, 2022
From what I understand, they want to publish
astro@1.0.0-beta.Xas thelatesttag on npm. I have the same requirement withariakit.Update 1: did a test here (
ariakit-changesets-test) and it looks like the alpha version has been published on thelatesttag, which is what I wanted for now. But now I'm confused. I would expect it would create a new dist-tag calledalpha. Am I missing something?Update 2: I now understand that it was released on the
latesttag because I didn't have any stable release on theariakit-changesets-testpackage.Update 3: I was able to force the
latesttag on the prerelease by using thepublishConfigfield on the package.json file.Andarist commentedon Apr 7, 2022
Yes, the
latesttag has to be set to something - that's a requirement of the npm registry.Interesting. So you have just added something like this?
{ "publishConfig": { "tag": "latest" } }Which npm client do you use?
FredKSchott commentedon Apr 7, 2022
Interesting! @diegohaz Did this work automatically with
changesets publish, or did you have to define your own publish step using pnpm/yarn/npm, outside of changesets?Andarist commentedon Apr 7, 2022
I'm pretty sure that this is not handled by Changesets and that it might only be handled by some package managers (I'm unsure which ones support this).
FredKSchott commentedon Apr 7, 2022
@Andarist apologies for missing this! We're in the middle of a big launch week which has been quite busy 😅 . If you're interested in joining us in Discord, we could do this async but maybe a bit more high-touch? astro.build/chat
Otherwise, happy to keep debugging here!
diegohaz commentedon Apr 7, 2022
I'm using npm 8. I think publishConfig is a feature of npm.
FredKSchott commentedon Apr 7, 2022
@Andarist honestly, I'm starting to think we might want to fork changesets, and do an astro-specific hack to get us through the next 2 months. I keep getting stuck on ideas:
npm dist-tag add astro@1.0.0-beta.X lateststep to our GitHub Action, so thatlatestalways matches beta (okay, but we need this for all packages in the monorepo, not just Astro)npm dist-tag add X@Y lateststep to our GitHub Action, so thatlatestalways matches beta for all packages in the monorepo (okay, but non-Astro dependencies are getting the-beta.1unnecessarily. We kind of want them to be non-beta, non-pre, normal semver)I think the smallest fork we could make, would be to keep the monorepo in normal mode, but then surgically overwrite whatever internal logic handles version bumping, to just always handle
"astro"as a special case to always bump as1.0.0-beta${X+1}. Everything else about normal "non-pre" mode would remain the same.@Andarist what do you think?
Edit: From poking around the codebase, I feel like this is where the one-off would live:
changesets/packages/assemble-release-plan/src/increment.ts
Line 13 in ab8f2b2
Edit 2: Yup, adding this line to that file above created a correct
changeset versionoutput:Andarist commentedon Apr 8, 2022
Yeah, forking seems to be the easiest solution to this - especially given that you only need this temporarily~.
In general, Changesets has not been designed to handle multiple independent "release plans". It's not impossible to add support for those... but it raises the complexity quite a bit because we would have to consider how parallel release plans interact with each other, can they overlap somehow? Can A from RP1 depend on B from RP2? etc etc. This would require deeper thought, analysis, and implementation - and, unfortunately, I'm so slammed with piling OSS issues that I just don't have capacity to do all of this on my own.
matthewp commentedon Apr 8, 2022
@Andarist
No, the tag should be
latest.This doesn't seem to go against what changeset is doing that much to me. We just want it to be the
latesttag instead of the beta tag.@FredKSchott
Do we? Why? It seems perfectly fine for everything to be marked with the beta version but still tagged latest. I could see possible accidental breakage if we started releasing patches that go out to 0.26.x users on the non-astro projects that implicitly only work with astro beta.
I agree with @Andarist here that this is the part that seems undoable with how changeset works, you're either in pre-mode or not. I think being in pre-mode for everything is fine, but just with the difference of the tag being
latestrather than the pre tag (beta, in this case).Andarist commentedon Apr 8, 2022
Maybe we could actually respect
publishConfig.tagif that's a thing supported by other tools - I would love to know which tools actually support this.This implies though that all your versions would be "preversions" - the only difference would be in the published tag.
diegohaz commentedon Apr 8, 2022
From what I tested, Changesets already supports this (maybe npm just forces this tag and ignores whatever tag you pass to the npm publish command).
As for other tools, I've used the same approach with lerna in the past.
feat: prerelease channels (branch-based, no committed prerelease vers…