Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

v8.0.0 #444

Merged
merged 14 commits into from
Feb 8, 2021
Merged

v8.0.0 #444

merged 14 commits into from
Feb 8, 2021

Conversation

G-Rath
Copy link
Member

@G-Rath G-Rath commented Feb 5, 2021

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 have typescript-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

@G-Rath G-Rath added the Type: Feature New feature or request label Feb 5, 2021
@ghost ghost added this to Features in JS Feb 5, 2021
@G-Rath
Copy link
Member Author

G-Rath commented Feb 5, 2021

@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 :)

wolfy1339
wolfy1339 previously approved these changes Feb 5, 2021
@gr2m
Copy link
Contributor

gr2m commented Feb 5, 2021

just a quick note: because this is a release branch (next) which has special meaning to semantic-release, do not do any rebasing and force pushing. And we should merge this PR using Rebase and merge instead of squashing. semantic-release is using git notes to keep track of preview releases. If we would do any squashing or force-pushing we would loose that state

@G-Rath
Copy link
Member Author

G-Rath commented Feb 5, 2021

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 馃檪)

Copy link
Contributor

@gr2m gr2m left a 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?

// ************************************************************
// DEPRECATIONS RETRO-COMPATIBILITY
// ************************************************************
export function webhookErrorTestDeprecated(error: WebhookError) {
const { request } = error;
console.log(request);
}

scripts/generate-types.ts Show resolved Hide resolved
@G-Rath G-Rath requested review from wolfy1339 and gr2m February 5, 2021 19:20
@gr2m gr2m changed the title Next v8.0.0 Feb 5, 2021
@gr2m
Copy link
Contributor

gr2m commented Feb 5, 2021

I wonder, now that we have explicit event handlers .onAny and .onError, we should probably throw if someone tries to listen to "*" or "error" events, as we use these strings internally to keep track of the .onAny/.onError calls. Rather an edge case and it would fail when compiling TypeScript, but might be worth to throw a useful error anyway at least for v8.x to help people upgrade

@gr2m
Copy link
Contributor

gr2m commented Feb 5, 2021

btw next time let's create a beta branch for pre-releases, that will create 8.0.0-beta.1, 8.0.0-beta.2, etc. Once we think it's ready, we can still go through a next branch to have more people test it before flagging it as @latest on npm/GitHub releases

@G-Rath
Copy link
Member Author

G-Rath commented Feb 7, 2021

Bamn! I've refactored the types based off #441 (thanks @jablko 鉂わ笍), and updated the typescript section of the README.

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 EmitterWebhookEvent to WebhookEvent as its a bit shorter and now makes more sense? Plus a few others 馃

@G-Rath G-Rath marked this pull request as ready for review February 7, 2021 22:37
@lumaxis

This comment has been minimized.

wolfy1339
wolfy1339 previously approved these changes Feb 8, 2021
} from "@octokit/webhooks-definitions/schema";
import type { emitterEventNames } from "./generated/webhook-names";

export type EmitterWebhookEventName = typeof emitterEventNames[number];
Copy link
Contributor

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.

Copy link
Member Author

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 馃槄

@jablko
Copy link
Contributor

jablko commented Feb 8, 2021

Can we land #443, #447, and #441, which this branch incorporates, to separate the breaking from non-breaking changes?


export type EmitterWebhookEventName = typeof emitterEventNames[number];
export type EmitterWebhookEvent<
TEmitterEvent extends EmitterWebhookEventName = EmitterWebhookEventName
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

Copy link
Member Author

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,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

Copy link
Member Author

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.

@G-Rath
Copy link
Member Author

G-Rath commented Feb 8, 2021

Can we land #443, #447, and #441, which this branch incorporates, to separate the breaking from non-breaking changes?

I class all these changes as breaking, because of the size of the refactors, and would just in general like to get v8 landed.
While we could land these in 7.x, if there is further bug fixing to be done we'd not be able to land those once we've landed 8.x, so might as well just go to 8.x.

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];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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)?

Copy link
Member Author

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 馃し馃檪

Copy link
Contributor

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:

> = TEmitterEvent extends `${infer TWebhookEvent}.${infer TAction}`

@gr2m
Copy link
Contributor

gr2m commented Feb 8, 2021

Can we land #443, #447, and #441, which this branch incorporates, to separate the breaking from non-breaking changes?

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 agree. Sorry @jablko. The upgrade to v8 shouldn't be too hard.

@gr2m while everyones approved this, I'll leave the releasing in your hands since I don't want to mess it up 馃槄

I got it

@gr2m gr2m merged commit 1891034 into master Feb 8, 2021
JS automation moved this from Features to Done Feb 8, 2021
@gr2m gr2m deleted the next branch February 8, 2021 18:38
@gr2m
Copy link
Contributor

gr2m commented Feb 8, 2021

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

@G-Rath
Copy link
Member Author

G-Rath commented Feb 8, 2021

Feel free to blame that on me 馃槄 next time I'll not call the branch next

@oscard0m
Copy link
Member

oscard0m commented Feb 8, 2021

Besides the automatic release not working, how was it? All working and shinning?

@github-actions
Copy link
Contributor

馃帀 This PR is included in version 8.0.3 馃帀

The release is available on:

Your semantic-release bot 馃摝馃殌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature New feature or request
Projects
No open projects
JS
  
Done
Development

Successfully merging this pull request may close these issues.

TypeScript section in Readme out of date?
6 participants