Yeah, that’s on Redwood to avoid breaking this behavior IMO, I had the same problem in the past too - but this is the right way to do it
this could have been prevented by declaring a peer dependency. redwood uses explicit semver for breaking changes.
( Just to be explicit for folks reading the thread, this is Redwood moving where a type was exported in an internal package which accidentally broke the dependencies in both cases. A peer dependency wouldn’t have changed anything here )
oh my bad. if it wasn’t labelled as a breaking change just because it was internal then that’s right.
we can stop the discussion anyway. I don’t think we could agree …
and not just telling me but adressing outsider feels like you don’t want to discuss anymore.
so it’s okay, we can agree to disagree.
Sorry, I also think this sucks, that was my intention of the post - to agree with you. It breaks userland code and userland libs like mine and zenstack’s) and should have had a shim or ideally not happened because folks rely on it as an implementation detail
1 Like