-
Notifications
You must be signed in to change notification settings - Fork 79
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(deps): move @octokit/webhooks-definitions
to non-dev deps
#439
Conversation
I'm okay with moving ahead to help resolve #436, but I'm concerned that making |
@@ -22,13 +22,13 @@ | |||
"prettier": {}, | |||
"dependencies": { | |||
"@octokit/request-error": "^2.0.2", | |||
"@octokit/webhooks-definitions": "3.57.2", |
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 this is a tough one - I think if we're going to make this a dependency (peer or otherwise) we should loosen our constraints to enable deduplication and getting fixes etc.
This will technically open us up for becoming out of sync, but the chances and implications of that are very minor: the only changes in the library that impacts us here is if we add/remove/change an event (as in, event name), which can be worked around as outlined in #434 (i.e, with casting, and because we're not erroring on unknown events, the user would just get a warning).
@gr2m you beat me to it 😅 While I think in the long-run moving them to So either we: I think B. is probably the way to go given the size of things, and the way bundles work (specifically, they'll often just always include it in full as its a production dependenecy, with little way to exclude) |
I'm trying to avoid B if possible, I did so far with all the other I think I'd go with A for now. I think the event types should go in a separate repository or into |
Is it possible to get a bundle size comparison before and after this change? |
@oscard0m that's very dependent on how you're bundling - since we never import the dependency in js code (only in TS) it should be very easy for bundlers to not include it (i.e The only reason it'd get included is if the bundler just rolled in every production-level dependency, which'll bring in a lot of other things too. This change will mean packers like (I'm interested in the size changes too, just wanted to give some background info to showcase that "bundle size" is a very contextual thing) |
That makes a total of 4MB |
btw, I think it's worth considering how we could ship the payload examples in their own package too at some point, as they're completely unneeded for the schema validation (tbh idk what use-case they have now in the published package that we've got the schemas). |
I agree, now that we have the schema, I think the examples are no longer necessary. I don't mind publishing them though, this will become less of an issue once we stop having |
I mean, the payloads make up the bulk of the package:
Removing them would make it far easier to justify having |
let's discuss this in https://github.com/octokit/webhooks. I'd say the 4MB extra in the install dependency tree is a problem when it's a problem |
A use case coming to my mind would be a unit test where a user wants to an example as a mocked response. Still, this would have sense to be a |
@gr2m FYI this seems to even be blowing up "lock file maintenance" PRs, e.g. https://github.com/renovatebot/auto-cancel-actions/pull/59/checks?check_run_id=1851162719 |
Yes, I was able to reproduce it. @wolfy1339 @G-Rath @oscard0m unless any of you object, let's get this merged an released. We can worry about bundle size later (via octokit/webhooks#362) |
@gr2m does solving this in a major release mean it won't "unbreak" semver-compatible ranges and therefore manual upgrading will be required? I didn't fully understand the interleaving requirements that lead to the breakage so may be mistaken. |
Yes. We could still fix the install problem by creating a pull request against the |
Breaking something in a minor release and fixing it in a major does not sound like being in the spirit of semver (again, assuming I'm not misunderstanding what happened here, and I'm still fuzzy). The thing is I don't actually know what I need to upgrade, as I pin my direct dependencies. My best guess is that our bot was broken due to a backwards incompatible change in a transitive dependency of probot. If so, can you officially mark all permanently broken versions of probot as deprecated on npmjs so it's more clear? |
🎉 This issue has been resolved in version 8.0.3 🎉 The release is available on: Your semantic-release bot 📦🚀 |
^bumping the above unanswered question |
I fully understand your frustrations. We don't usually consider TypeScript changes as breaking, since it's only used build time.
You can update to the latest version of
Yes, exactly. It goes Whenever there is a breaking change somewhere in the chain, it trickles up to probot
That would be up to @gr2m to do. |
I don't think that any probot version is permanently broken for all users. I know how semantic versioning works. We are doing our best to adhere to it. In this case something broke that is not easily reversible because it was a substantial change. Our tests should have caught that but didn't, that shouldn't happen again. Sorry for the friction @rarkins, but we have to move on. |
Ref: #436 (comment)