Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
The wrong dependents are generated in some rare cases with `linked` and changing to single file changesets
See original GitHub issuechangeset add currently doesn’t care about the linked option and that creates a problem if a package is bumped at a higher level because of linked which means there should be some dependents.
A, B and C are all linked together and they are all currently at 1.0.0. B has a dependency on C.
A changeset is added:
A@major
C@patch
There will be no dependents generated. When bumping though, A and C will both be released as 2.0.0 and B won’t be released which is wrong since its dependency on C is out of range now.
Issue Analytics
- State:
- Created 4 years ago
- Comments:16 (7 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Strong agree on adding it before a major.
Do you wanna try implementing it?
I was going to say that maybe I should seperate out the create changeset package in the GitHub comment PR to another PR that can be merged but practically all of the logic is about calculating dependents so it’s probably better to start from the current state rather than that. I’ll seperate some TS conversion things from that into another PR though.
Yeah I guess that would work. There’s something that slightly worries me about having an optional thing like that because I’m afraid we or others will accidentally assume that it always exists. (e.g. commit can technically be undefined right now but all the changelog entry generators i’ve seen/written assume it always exists)