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
feat: remove fixed versions @lion and upgrade TSC #1603
Conversation
🦋 Changeset detectedLatest commit: b4f6395 The changes in this PR will be included in the next version bump. This PR includes changesets to release 38 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 |
5f0f3af
to
03f70fc
Compare
|
I checked how changeset will deal with the non-fixed versions and my hypotheses were correct. While reviewing, feel free to double check by running: yarn changeset # do a patch for lion core, only core is bumped, do a minor for lion core, all other packages are bumped with patch
yarn changeset version # see the diff |
|
@tlouisse this PR is basically ready but we still need to add a changeset. In my opinion, unfixing the dependencies and upgrading to latest TSC, it's probably safe to say that this is bound to be a breaking change for someone at some point, do you agree doing a minor bump for all involved packages (that's basically everything in |
03f70fc
to
9628629
Compare
fa0520f
to
f50dc0f
Compare
0dd86ee
to
683d5c1
Compare
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.
Looks good to me, but i believe @tlouisse also wanted to review


What I did
@ts-ignore'd due to how bad TS is with JS mixins, the maintainer himself mentioned this is a classic example of where you should@ts-ignore, so that also means is that we should tell our users thatskipLibCheckin their TS configs is unavoidable. Hopefully TS becomes better at this stuff....WIP, I'm going to run some tests with changesets to see what happens if:
@lion/coredoes a patch bump --> I expect no bumps anywhere else, because in the other places we now use^which means end users will get latest@lion/corewith a fresh install of a dependent (let's say@lion/button), the patch bump is non-breaking and the dependents will be semver compatible@lion/coredoes a breaking change minor bump --> I expect bumps everywhere else because this is a breaking bump and thus semver incompatible bump for dependents (e.g.@lion/button). Changesets should patch the button so that our users will get the latest core with the latest button (but not the@lion/buttonbefore the bump!). If the@lion/corechange was actually breaking for@lion/button, of course since@lion/buttonis part of this repo we would manually bump@lion/buttonas we fix the breakage, if that fix leads to a breaking change in@lion/button, that will be a minor. Changesets only does a patch bump to ensure latest@lion/corecan end up at the end user if they only consume e.g.@lion/button, which would otherwise never happen because the old@lion/buttonhas@lion/corestuck at 1 minor before.We should be seeing way less bloat in our changelogs with this, since we'll only need dependents to bump for semver incompatible bumps which are minors
<1.0.0and majors>1.0.0.Broader discussion here: https://lit-and-friends.slack.com/archives/CJGFWJN9J/p1643202849020900 and also discussed at length with @tlouisse