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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ref(types): Avoid some any type casting around wrap code #14463

Merged
merged 2 commits into from
Nov 28, 2024
Merged

Conversation

mydea
Copy link
Member

@mydea mydea commented Nov 25, 2024

We use a heavy dose of any, that I would like to reduce.

So I started out to look into wrap(), which made heave use of this, and tried to rewrite it to avoid any as much as possible. This required some changes around it, but should now have much better type inferrence etc. than before, and be more "realistic" in what it tells you.

While at this, I also removed the before argument that we were not using anymore - wrap is not exported anymore, so this is purely internal.

@mydea mydea self-assigned this Nov 25, 2024
Copy link
Contributor

github-actions bot commented Nov 25, 2024

size-limit report 📦

Path Size % Change Change
@sentry/browser 23.12 KB -0.1% -22 B 🔽
@sentry/browser - with treeshaking flags 21.82 KB -0.2% -44 B 🔽
@sentry/browser (incl. Tracing) 35.53 KB -0.07% -22 B 🔽
@sentry/browser (incl. Tracing, Replay) 72.44 KB -0.03% -22 B 🔽
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags 62.81 KB -0.05% -31 B 🔽
@sentry/browser (incl. Tracing, Replay with Canvas) 76.76 KB -0.03% -21 B 🔽
@sentry/browser (incl. Tracing, Replay, Feedback) 89.22 KB -0.02% -15 B 🔽
@sentry/browser (incl. Feedback) 39.86 KB -0.04% -13 B 🔽
@sentry/browser (incl. sendFeedback) 27.74 KB -0.08% -20 B 🔽
@sentry/browser (incl. FeedbackAsync) 32.54 KB -0.06% -19 B 🔽
@sentry/react 25.79 KB -0.08% -20 B 🔽
@sentry/react (incl. Tracing) 38.37 KB -0.06% -20 B 🔽
@sentry/vue 27.27 KB -0.08% -22 B 🔽
@sentry/vue (incl. Tracing) 37.33 KB -0.06% -22 B 🔽
@sentry/svelte 23.27 KB -0.09% -20 B 🔽
CDN Bundle 24.31 KB -0.08% -19 B 🔽
CDN Bundle (incl. Tracing) 37.19 KB -0.07% -24 B 🔽
CDN Bundle (incl. Tracing, Replay) 72.06 KB -0.04% -25 B 🔽
CDN Bundle (incl. Tracing, Replay, Feedback) 77.4 KB -0.03% -23 B 🔽
CDN Bundle - uncompressed 71.42 KB -0.06% -37 B 🔽
CDN Bundle (incl. Tracing) - uncompressed 110.47 KB -0.04% -37 B 🔽
CDN Bundle (incl. Tracing, Replay) - uncompressed 223.54 KB -0.02% -37 B 🔽
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed 236.76 KB -0.02% -37 B 🔽
@sentry/nextjs (client) 38.69 KB -0.08% -31 B 🔽
@sentry/sveltekit (client) 36.05 KB -0.08% -28 B 🔽
@sentry/node 135.23 KB - -
@sentry/node - without tracing 97.04 KB -0.01% -1 B 🔽
@sentry/aws-serverless 107.29 KB - -

View base workflow run

Copy link

codecov bot commented Nov 25, 2024

❌ 1 Tests Failed:

Tests completed Failed Passed Skipped
364 1 363 70
View the full list of 1 ❄️ flaky tests
integrations/ContextLines/noAddedLines/test.ts should not add source context lines to errors from script files

Flake rate in main: 11.52% (Passed 215 times, Failed 28 times)

Stack Traces | 30.1s run time
test.ts:6:11 should not add source context lines to errors from script files

To view more test analytics, go to the Test Analytics Dashboard
📢 Thoughts on this report? Let us know!

@@ -31,6 +31,21 @@ export function ignoreNextOnError(): void {
});
}

// eslint-disable-next-line @typescript-eslint/ban-types
type WrappableFunction = Function;
Copy link
Member Author

Choose a reason for hiding this comment

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

Just an alias to avoid having ban-types eslint disable everywhere

// eslint-disable-next-line @typescript-eslint/ban-types
type WrappableFunction = Function;

export function wrap<T extends WrappableFunction>(
Copy link
Member Author

Choose a reason for hiding this comment

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

This ensures we have proper type inferrence, so e.g.

const a = wrap(1);
// a is correctly inferred as `1` now


// eslint-disable-next-line @typescript-eslint/no-unsafe-member-access, no-prototype-builtins
if (!proto || !proto.hasOwnProperty || !proto.hasOwnProperty('addEventListener')) {
if (!proto || Object.prototype.hasOwnProperty.call(proto, 'addEventListener')) {
Copy link
Member Author

Choose a reason for hiding this comment

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

is there a reason not to use Object.prototype.hasOwnProperty here, but use the prototype method itself? 🤔

Copy link
Member

@Lms24 Lms24 Nov 25, 2024

Choose a reason for hiding this comment

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

what's the difference between the two? shouldn't this be equal since we pass proto as the this arg? I guess the only apparent reason to me would be saving a couple of bytes. But if using Object.prototype.hasOwnProperty is more correct, we should go for it!

Copy link
Member Author

Choose a reason for hiding this comment

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

Well there is https://eslint.org/docs/latest/rules/no-prototype-builtins which is "fixed" by this, not sure how important this is though 🤔

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm, so there does seem to be a difference there 🤔 changing this changes the browser integration tests, target of the mechanism becomes Window or Node instead of EventTarget 🤔 not sure why, but I guess I'll leave this as it was then!

Copy link
Member

Choose a reason for hiding this comment

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

TIL, thanks! No objections to leaving it as-is :D

@@ -17,14 +17,14 @@ export function domainify<A extends unknown[], R>(fn: (...args: A) => R): (...ar
* @returns wrapped function
*/
// eslint-disable-next-line @typescript-eslint/no-explicit-any
export function proxyFunction<A extends any[], R, F extends (...args: A) => R>(
export function proxyFunction<F extends (...args: any[]) => unknown>(
Copy link
Member Author

Choose a reason for hiding this comment

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

sadly this somehow still has to be any, not quite sure why but didn't feel like investing more time into this...

@mydea mydea marked this pull request as ready for review November 25, 2024 16:06
@mydea mydea requested review from Lms24 and s1gr1d November 25, 2024 16:06
Copy link
Member

@Lms24 Lms24 left a comment

Choose a reason for hiding this comment

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

Generally LGTM! I like the type refactors. Had a concern with the GCP package type changes there. Can we extract these to their own PR (potentially when working on v9) and merge the browser/core changes in first?

Copy link
Member

@Lms24 Lms24 Nov 25, 2024

Choose a reason for hiding this comment

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

h: unfortunately, these types are public API because wrapHttpFunction, wrapCloudEventFunction and wrapEventFunction are exported and reference the types in their signature. Maybe we do this change in v9 instead?

@@ -56,16 +64,6 @@ describe('internal wrap()', () => {
expect(wrap(wrapped)).toBe(wrapped);
});

it('calls "before" function when invoking wrapped function', () => {
Copy link
Member

Choose a reason for hiding this comment

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

l: why did we remove this test? (I guess it's redundant but just wanted to double-check)

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 removed the before option from the function, it was not used anymore :)


// eslint-disable-next-line @typescript-eslint/no-unsafe-member-access, no-prototype-builtins
if (!proto || !proto.hasOwnProperty || !proto.hasOwnProperty('addEventListener')) {
if (!proto || Object.prototype.hasOwnProperty.call(proto, 'addEventListener')) {
Copy link
Member

@Lms24 Lms24 Nov 25, 2024

Choose a reason for hiding this comment

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

what's the difference between the two? shouldn't this be equal since we pass proto as the this arg? I guess the only apparent reason to me would be saving a couple of bytes. But if using Object.prototype.hasOwnProperty is more correct, we should go for it!

packages/browser/src/helpers.ts Outdated Show resolved Hide resolved
@mydea
Copy link
Member Author

mydea commented Nov 26, 2024

I extracted the gcp stuff out into #14476 👍

@mydea mydea merged commit be73e38 into develop Nov 28, 2024
153 checks passed
@mydea mydea deleted the fn/wrap-types branch November 28, 2024 12:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants