-
Notifications
You must be signed in to change notification settings - Fork 569
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
fix: Invalid comparator semver error when using tag versions #1047
fix: Invalid comparator semver error when using tag versions #1047
Conversation
🦋 Changeset detectedLatest commit: bdec3d0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
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. |
hey @Andarist! |
Hmm, the goal of the change looks OK to me. if you are using a tag - that's your choice and Changesets should leave this alone. However, I wonder if your use case is correct - snapshot releases were not designed to be committed. Whatever changes they make to |
@@ -84,14 +84,15 @@ export default function versionPackage( | |||
depCurrentVersion = workspaceDepVersion; | |||
} | |||
if ( | |||
semver.validRange(depCurrentVersion) !== null && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tags should already be allowed (and ignored), please take a look at the logic here:
changesets/packages/get-dependents-graph/src/get-dependency-graph.ts
Lines 114 to 118 in 87e9bb8
// `depRange` could have been a tag and if a tag has been used there might have been a reason for that | |
// we should not count this as a local monorepro dependant | |
if (!range) { | |
continue; | |
} |
So if this isn't working for you... I wonder what went wrong in between. Why do we end up with a release for a package here if it's not part of the dep graph? Or is the package in question (example package) versioned on its own as well - so it wasn't pulled into the whole release by its dependencies but it's rather released on its own? If that's the case - why is it released/versioned? Could it be avoided?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably because the package itself is correct and we're upgrading this package version; but then it detects other dependency packages which are in monorepo and tries to upgrade this dependencies as well, which are marked as tags - and this is where the problem is. If you'd revert change that test will not pass with exactly the error I'm having while changeset version
is invoked
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if we take vue-demo-store
as an example of this issue - do you explicitly create a changeset file for this vue-demo-store
package? If yes - what for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so you have
/packages
/package-a --> 0.1.0
/templates
/some-template --> 0.2.3
dependency to package-a -> not workspace:* but TAG_NAME
so when you add changeset to some-template
we should have it as for example 0.2.4
and nothing else. andwhen you update package-a
then dependency at some-template
should not change even if some-template
has a correct range version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if we take
vue-demo-store
as an example of this issue - do you explicitly create a changeset file for thisvue-demo-store
package? If yes - what for?
yes, we do create changeset for that, reasoning:
vue-demo-store is a template, it's not published on npm as it's not upgradable, but also templates have their issues, so thanks to that we want to keep changelog for templates which features/fixes were added and when (versioning them). It helps to keep cleaner history of changes and inform our users what has changed since last time they used this template
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a version-level test for this that would depict the whole flow more closely? You can add it here. Th test case that you already added shouldn't be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure! I'm on it
@Andarist thank you for your response. Maybe I wasn't clear but definitely we're not committing snapshots, but on the other hand we have stackblitz templates which should work with current master branch (so snapshot) published on npm, that's why templates are using snapshot tag, but on local envs it resolves to packages from monorepo. Quick real life case: But having this setup it crasches during |
Could you take a look at my other comment? I feel like I'm missing something about the nature of this bug (or your setup) - and I would like to commit this change only after understanding the full picture. |
Great, I appreciate you taking the time to dive deeper into that to understand my issue. I'm aware this setup is not a common one, but I have good reasons for that, which I hope are also making sense to you :) |
hey @Andarist, can I ask you to re-review this one? :) |
@Andarist really sorry to ping you like this all the time :( |
hello @Andarist, you're probably busy, it there anyone else I could ping to make this go forward? |
Hey @Andarist, as a patch it's working for 5 months now. Is there anything blocking you from merging that? Just to refresh memory - it's just making sure the whole process is not failing when we have an npm tag version instead of semver. |
@patzick could you resolve conflicts here? Sorry for not getting back to you earlier here |
@Andarist, no problem, thanks for getting back at this! The conflict was caused by this: https://github.com/changesets/changesets/pull/1176/files#diff-73bc94618d4ce1bc263e6ecb9e90dee49072a5d789137c6b530dccd1f99fbcabL91-R95 |
* chore: bump dependencies * chore: revert i18n plugin update * chore: new patch after update, related changesets/changesets#1047 * chore: add changeset
* chore: bump dependencies * chore: revert i18n plugin update * chore: new patch after update, related changesets/changesets#1047 * chore: add changeset
Hey @Andarist, can you merge it? After the new release, I needed to patch it once again in our code and I see new merge movements so probably new release is coming soon :) |
* chore: bump dependencies * chore: revert i18n plugin update * chore: new patch after update, related changesets/changesets#1047 * chore: add changeset
LGTM, it only needs some minor code shuffling related to the added test case. |
@@ -1356,6 +1356,111 @@ describe("apply release plan", () => { | |||
}, | |||
}); | |||
}); | |||
it("should not update internal version for tags", async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder, is this case right now? Shouldn't it be just using a pkg-a: patch
changeset or smth like that to test that pkg-b doesn't get updated transitively? Perhaps I misunderstand the intention of this test though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose of this test is that dependencies
are not changed (not bumped) as they're using the tag
version, not a numeric version. So even if both packages are updated, they should not change anything inside dependencies as tags should be static, not semver specific :)
Woah, I somehow missed that there was another question here. As I thought |
Hey @Andarist - is there anything else keeping you from merging this PR? Let me know if I can assist somehow more to go through with that! |
hey @Andarist! |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1047 +/- ##
==========================================
+ Coverage 80.99% 81.02% +0.02%
==========================================
Files 54 54
Lines 2210 2213 +3
Branches 652 654 +2
==========================================
+ Hits 1790 1793 +3
Misses 416 416
Partials 4 4 ☔ View full report in Codecov by Sentry. |
Hello, @Andarist, I see some movements in the repo. |
@@ -3,6 +3,7 @@ import { ChangelogFunctions, NewChangesetWithCommit } from "@changesets/types"; | |||
import { ModCompWithPackage } from "@changesets/types"; | |||
import startCase from "lodash.startcase"; | |||
import { shouldUpdateDependencyBasedOnConfig } from "./utils"; | |||
import validRange from "semver/ranges/valid"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also try doing smth about invalid tags (as in - continue to throw). To check what a valid tag is we could do:
function isValidTag(tag: string) {
return encodeURIComponent(tag) === tag;
}
This can be verified here.
But honestly, I don't think it's worth it.
Respect! 💙 |
Hey, great job with the project!
Small fix to cover the case when you're using tag versions.
Let's say you publish snapshots on npm with our
bulbosaur
example from docs :)You have examples in monorepo which can be fired from web container like stackblitz or codesandbox, but we don't want (and should not) commit snapshot releases with versions back to repo. Tags are solutions to that problem, yet they're not a valid semver ranges, so we have for example (my case is
canary
tag):which breaks whole release. I'll be very grateful for quickly releasing this fix if all looks good for you here. Cheers!