-
Notifications
You must be signed in to change notification settings - Fork 82
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
v8.0.0 #444
Conversation
BREAKING CHANGE: passing `error` as an event name is no longer supported
BREAKING CHANGE: passing `*` as an event name is no longer supported
BREAKING CHANGE: payload types have been renamed and refactored
@anstarovoyt @prigara the performance problems are pretty massive & showstopping, and it'd be very easy for a package to ship with types that'd grind things to a halt so it'd be great to get this resolved quickly. Happy to help anyway I can :) |
just a quick note: because this is a release branch ( |
Yeah, sorry I didn't know it was setup to do a pre-release (which is very cool, and didn't know you could do - might "borrow" that config for some of my other projects) 😓 Any follow up changes I'll do to this branch via PR, but it seems like it's good to go already 🤷 Are there any other breaking changes you'd talked about doing previously that could be included? (also @gr2m I'll let you do the merging for this one 🙂) |
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 can also remove this from the tests I think?
webhooks.js/test/typescript-validate.ts
Lines 199 to 206 in 2db33e5
// ************************************************************ | |
// DEPRECATIONS RETRO-COMPATIBILITY | |
// ************************************************************ | |
export function webhookErrorTestDeprecated(error: WebhookError) { | |
const { request } = error; | |
console.log(request); | |
} |
I wonder, now that we have explicit event handlers |
btw next time let's create a |
Bamn! I've refactored the types based off #441 (thanks @jablko ❤️), and updated the I think this is now good to go, unless anyone has any other changes they think we could ship in this major? The only other thing off the top of my head that I could do is renaming the types to be consistent - they're mostly already fine now, but we could rename |
This comment has been minimized.
This comment has been minimized.
} from "@octokit/webhooks-definitions/schema"; | ||
import type { emitterEventNames } from "./generated/webhook-names"; | ||
|
||
export type EmitterWebhookEventName = typeof emitterEventNames[number]; |
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.
What made you decide to revert the type alias in the generated type? #441 (comment)
I don't have a strong opinion, just curious.
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 just found it was nicer to have everything being imported from the same place, rather than having an extra import line 😅
|
||
export type EmitterWebhookEventName = typeof emitterEventNames[number]; | ||
export type EmitterWebhookEvent< | ||
TEmitterEvent extends EmitterWebhookEventName = EmitterWebhookEventName |
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.
TEmitterEvent extends EmitterWebhookEventName = EmitterWebhookEventName | |
TEmitterEvent extends EmitterWebhookEventName = WebhookEventName |
I don't know if it makes a difference, but in #441 I went with WebhookEventName
here because EmitterWebhookEvent<WebhookEventName>
is functionally equivalent to EmitterWebhookEvent<EmitterWebhookEventName>
and WebhookEventName
is smaller than EmitterWebhookEventName
so I thought it might perform better? https://github.com/jablko/webhooks.js/compare/patch-2..octokit:next#diff-c54113cf61ec99691748a3890bfbeb00e10efb3f0a76f03a0fd9ec49072e410aL14-R10
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'd prefer to use the most accurate type - if it was causing more performance problems, I'd want to know about them here since you could still run into them in userland by using that type :)
> { | ||
import { RequestError } from "@octokit/request-error"; | ||
import type { | ||
WebhookEventMap, |
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.
WebhookEventMap, | |
EventPayloadMap, |
No strong opinion, but to my eye EventPayloadMap
makes it clearer that this is a map from WebhookEventName
-> payload vs. WebhookEventName
-> event? https://github.com/jablko/webhooks.js/compare/patch-2..octokit:next#diff-c54113cf61ec99691748a3890bfbeb00e10efb3f0a76f03a0fd9ec49072e410aL3-R3
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.
It's a map of webhook events - the fact that it's called "Payload" is a remnant of previous versions, and at some point will likely be removed.
I class all these changes as breaking, because of the size of the refactors, and would just in general like to get v8 landed. I don't mind reverting the all the type refactor stuff in 7.x so that people can stay on that longer if they want? @gr2m while everyones approved this, I'll leave the releasing in your hands since I don't want to mess it up 😅 |
} from "@octokit/webhooks-definitions/schema"; | ||
import type { emitterEventNames } from "./generated/webhook-names"; | ||
|
||
export type EmitterWebhookEventName = typeof emitterEventNames[number]; |
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.
export type EmitterWebhookEventName = typeof emitterEventNames[number]; | |
export type EmitterEventName = typeof emitterEventNames[number]; |
What do you think of just EmitterEventName
, now every EmitterEventName
is an EmitterWebhookEventName
("*"
and "error"
having been 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.
yup, but I'm not so concerned about that since its still accurate with the current name, and everyones approved this 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.
Following the pattern of TEmitterEvent
vs. TWebhookEvent
:
Line 11 in fc5277d
> = TEmitterEvent extends `${infer TWebhookEvent}.${infer TAction}` |
I agree. Sorry @jablko. The upgrade to v8 shouldn't be too hard.
I got it |
well the automation didn't work for some reason 🤷🏼 but I've fixed it manually. Version 8.0.2 is now the latest on npm and GitHub |
Feel free to blame that on me 😅 next time I'll not call the branch |
Besides the automatic release not working, how was it? All working and shinning? |
🎉 This PR is included in version 8.0.3 🎉 The release is available on: Your semantic-release bot 📦🚀 |
I've done this all in one PR as there's some overlapping changes and I think it's just easier to review as a whole. There are a few changes I'll look to pull out (specifically the test & typo fixings).
I think this is pretty much good to go, but going to make it a draft for now all the same.
Closes #439
Closes #440
Closes #441
Closes #443
Closes #445
Closes #447
I've deliberately not applied the main change from #441 as while it's nice not to have the file, it causes massive performance issues in my IDE which I think are not worth the trade off since it'll occur for other WebStorm users.
There's also a performance problem when having to infer the generic for
TTransformed
, but that can be worked around by just providing the generic explicitly so so long as I don't havetypescript-validate
open I can still work on the project without issue 😅I have opened a ticket in YouTrack, and will hopefully be able to get that resolved.
Also, we could revert the type refactoring on 7.x.x so that
probot
and co wouldn't have as a sad time, and then just include that refactor in this release.View rendered .github/ISSUE_TEMPLATE/04_feature_request.md
View rendered README.md