fix(utils): Prevent iterating over VueViewModel by Duncanxyz · Pull Request #8981 · getsentry/sentry-javascript

Duncanxyz · 2023-09-08T02:46:50Z

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

If you've added code that should be tested, please add tests.
Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

Lms24

Hi @Duncanxyz thanks for opening this PR! I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

Lms24 · 2023-09-08T07:47:17Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


well I guess there's precedence for handling this stuff like this in a general package of ours 😅

the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

Duncanxyz · 2023-09-12T07:19:05Z

I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I agree, this is not an elegant solution. Perhaps in the future, we can implement it through a plugin approach, where additional handling can be injected when referencing framework-specific packages (e.g., @sentry/vue).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

I took the naming reference from @sentry/vue. The _isVue (vue2) and __isVue (vue3) properties are only used to determine if it's a Vue instance, while there are other Vue object type checks like __v_isRef, __v_isReactive, and __v_isVNode. However, the current issue usually occurs only on Vue instance objects.

My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2. After your reminder, I finded that Vue 3 had similar issues and handling before (#4743, #5916, #6014), which essentially were caused by accessing illegal properties of the Vue instance during the rendering process, and warning in Vue's DEV mode. I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

Lms24

Thank you for explaining!

Perhaps in the future, we can implement it through a plugin approach

Maybe, yes - good idea! But for now, this is fine.

However, the current issue usually occurs only on Vue instance objects.
My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

No, after reading your explanations, I think it's fine to keep it as-is.

I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

So just to confirm before we ✅ , this PR currently fixes an issue that's only present in Vue 2 and Vue 3 is not affected by this PR? Then we're good :)

…eadcrumb 1. Preserve the original behavior of console. 2. Centralize special handling for Vue in the utils module.

Duncanxyz · 2023-09-12T10:41:22Z

#8981 (comment)
I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2.

I made a mistake; Vue 3 also has issues, just with different colors 😅. The code I just submitted includes compatibility optimizations for both Vue 2 and Vue 3.

vue2:

vue3:

Lms24

Thank you for reworking this! I think this looks good for now. In case we run into problems we can always revisit.

AbhiPrasad · 2023-09-08T12:36:52Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24 · 2023-09-13T06:54:34Z

@Duncanxyz this will go out in version 7.69.0 in the next couple of hours. Thanks again!

The isVueViewModel() and getVueInternalName() functions from is.ts and stacktrace.ts were only called from two sites: normalize.ts (stringifyValue) and string.ts (safeJoin). Inlining the checks directly at these call sites allows tree-shaking to eliminate the standalone function definitions from bundles that pull in normalize/string but not is.ts for other reasons. Uses the `in` operator instead of `as any` casts to satisfy the linter's no-explicit-any / no-unsafe-member-access rules. The Vue check prevents infinite console warning loops when stringifying Vue 2/3 ViewModel instances or VNodes (see #8981). Saves ~15 bytes gzipped on the base browser bundle. Co-Authored-By: Claude claude@anthropic.com

Duncanxyz · 2023-09-08T02:46:50Z

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

If you've added code that should be tested, please add tests.
Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

close#8980

Lms24

Hi @Duncanxyz thanks for opening this PR! I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

Lms24 · 2023-09-08T07:47:17Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


well I guess there's precedence for handling this stuff like this in a general package of ours 😅

the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

Duncanxyz · 2023-09-12T07:19:05Z

I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I agree, this is not an elegant solution. Perhaps in the future, we can implement it through a plugin approach, where additional handling can be injected when referencing framework-specific packages (e.g., @sentry/vue).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

I took the naming reference from @sentry/vue. The _isVue (vue2) and __isVue (vue3) properties are only used to determine if it's a Vue instance, while there are other Vue object type checks like __v_isRef, __v_isReactive, and __v_isVNode. However, the current issue usually occurs only on Vue instance objects.

My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2. After your reminder, I finded that Vue 3 had similar issues and handling before (#4743, #5916, #6014), which essentially were caused by accessing illegal properties of the Vue instance during the rendering process, and warning in Vue's DEV mode. I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

Lms24

Thank you for explaining!

Perhaps in the future, we can implement it through a plugin approach

Maybe, yes - good idea! But for now, this is fine.

However, the current issue usually occurs only on Vue instance objects.
My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

No, after reading your explanations, I think it's fine to keep it as-is.

I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

So just to confirm before we ✅ , this PR currently fixes an issue that's only present in Vue 2 and Vue 3 is not affected by this PR? Then we're good :)

…eadcrumb 1. Preserve the original behavior of console. 2. Centralize special handling for Vue in the utils module.

Duncanxyz · 2023-09-12T10:41:22Z

#8981 (comment)
I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2.

I made a mistake; Vue 3 also has issues, just with different colors 😅. The code I just submitted includes compatibility optimizations for both Vue 2 and Vue 3.

vue2:

vue3:

Lms24

Thank you for reworking this! I think this looks good for now. In case we run into problems we can always revisit.

AbhiPrasad · 2023-09-08T12:36:52Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24 · 2023-09-13T06:54:34Z

@Duncanxyz this will go out in version 7.69.0 in the next couple of hours. Thanks again!

The isVueViewModel() and getVueInternalName() functions from is.ts and stacktrace.ts were only called from two sites: normalize.ts (stringifyValue) and string.ts (safeJoin). Inlining the checks directly at these call sites allows tree-shaking to eliminate the standalone function definitions from bundles that pull in normalize/string but not is.ts for other reasons. Uses the `in` operator instead of `as any` casts to satisfy the linter's no-explicit-any / no-unsafe-member-access rules. The Vue check prevents infinite console warning loops when stringifying Vue 2/3 ViewModel instances or VNodes (see #8981). Saves ~15 bytes gzipped on the base browser bundle. Co-Authored-By: Claude claude@anthropic.com

Duncanxyz · 2023-09-08T02:46:50Z

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

If you've added code that should be tested, please add tests.
Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

close#8980

Lms24

Hi @Duncanxyz thanks for opening this PR! I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

Lms24 · 2023-09-08T07:47:17Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


well I guess there's precedence for handling this stuff like this in a general package of ours 😅

the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

Duncanxyz · 2023-09-12T07:19:05Z

I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I agree, this is not an elegant solution. Perhaps in the future, we can implement it through a plugin approach, where additional handling can be injected when referencing framework-specific packages (e.g., @sentry/vue).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

I took the naming reference from @sentry/vue. The _isVue (vue2) and __isVue (vue3) properties are only used to determine if it's a Vue instance, while there are other Vue object type checks like __v_isRef, __v_isReactive, and __v_isVNode. However, the current issue usually occurs only on Vue instance objects.

My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2. After your reminder, I finded that Vue 3 had similar issues and handling before (#4743, #5916, #6014), which essentially were caused by accessing illegal properties of the Vue instance during the rendering process, and warning in Vue's DEV mode. I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

Lms24

Thank you for explaining!

Perhaps in the future, we can implement it through a plugin approach

Maybe, yes - good idea! But for now, this is fine.

However, the current issue usually occurs only on Vue instance objects.
My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

No, after reading your explanations, I think it's fine to keep it as-is.

I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

So just to confirm before we ✅ , this PR currently fixes an issue that's only present in Vue 2 and Vue 3 is not affected by this PR? Then we're good :)

…eadcrumb 1. Preserve the original behavior of console. 2. Centralize special handling for Vue in the utils module.

Duncanxyz · 2023-09-12T10:41:22Z

#8981 (comment)
I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2.

I made a mistake; Vue 3 also has issues, just with different colors 😅. The code I just submitted includes compatibility optimizations for both Vue 2 and Vue 3.

vue2:

vue3:

Lms24

Thank you for reworking this! I think this looks good for now. In case we run into problems we can always revisit.

AbhiPrasad · 2023-09-08T12:36:52Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24 · 2023-09-13T06:54:34Z

@Duncanxyz this will go out in version 7.69.0 in the next couple of hours. Thanks again!

The isVueViewModel() and getVueInternalName() functions from is.ts and stacktrace.ts were only called from two sites: normalize.ts (stringifyValue) and string.ts (safeJoin). Inlining the checks directly at these call sites allows tree-shaking to eliminate the standalone function definitions from bundles that pull in normalize/string but not is.ts for other reasons. Uses the `in` operator instead of `as any` casts to satisfy the linter's no-explicit-any / no-unsafe-member-access rules. The Vue check prevents infinite console warning loops when stringifying Vue 2/3 ViewModel instances or VNodes (see #8981). Saves ~15 bytes gzipped on the base browser bundle. Co-Authored-By: Claude claude@anthropic.com

Duncanxyz · 2023-09-08T02:46:50Z

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

If you've added code that should be tested, please add tests.
Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

close#8980

Lms24

Hi @Duncanxyz thanks for opening this PR! I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

Lms24 · 2023-09-08T07:47:17Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


well I guess there's precedence for handling this stuff like this in a general package of ours 😅

the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

Duncanxyz · 2023-09-12T07:19:05Z

I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I agree, this is not an elegant solution. Perhaps in the future, we can implement it through a plugin approach, where additional handling can be injected when referencing framework-specific packages (e.g., @sentry/vue).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

I took the naming reference from @sentry/vue. The _isVue (vue2) and __isVue (vue3) properties are only used to determine if it's a Vue instance, while there are other Vue object type checks like __v_isRef, __v_isReactive, and __v_isVNode. However, the current issue usually occurs only on Vue instance objects.

My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2. After your reminder, I finded that Vue 3 had similar issues and handling before (#4743, #5916, #6014), which essentially were caused by accessing illegal properties of the Vue instance during the rendering process, and warning in Vue's DEV mode. I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

Lms24

Thank you for explaining!

Perhaps in the future, we can implement it through a plugin approach

Maybe, yes - good idea! But for now, this is fine.

However, the current issue usually occurs only on Vue instance objects.
My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

No, after reading your explanations, I think it's fine to keep it as-is.

I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

So just to confirm before we ✅ , this PR currently fixes an issue that's only present in Vue 2 and Vue 3 is not affected by this PR? Then we're good :)

…eadcrumb 1. Preserve the original behavior of console. 2. Centralize special handling for Vue in the utils module.

Duncanxyz · 2023-09-12T10:41:22Z

#8981 (comment)
I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2.

I made a mistake; Vue 3 also has issues, just with different colors 😅. The code I just submitted includes compatibility optimizations for both Vue 2 and Vue 3.

vue2:

vue3:

Lms24

Thank you for reworking this! I think this looks good for now. In case we run into problems we can always revisit.

AbhiPrasad · 2023-09-08T12:36:52Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24 · 2023-09-13T06:54:34Z

@Duncanxyz this will go out in version 7.69.0 in the next couple of hours. Thanks again!

The isVueViewModel() and getVueInternalName() functions from is.ts and stacktrace.ts were only called from two sites: normalize.ts (stringifyValue) and string.ts (safeJoin). Inlining the checks directly at these call sites allows tree-shaking to eliminate the standalone function definitions from bundles that pull in normalize/string but not is.ts for other reasons. Uses the `in` operator instead of `as any` casts to satisfy the linter's no-explicit-any / no-unsafe-member-access rules. The Vue check prevents infinite console warning loops when stringifying Vue 2/3 ViewModel instances or VNodes (see #8981). Saves ~15 bytes gzipped on the base browser bundle. Co-Authored-By: Claude claude@anthropic.com

Duncanxyz · 2023-09-08T02:46:50Z

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

If you've added code that should be tested, please add tests.
Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

close#8980

Lms24

Hi @Duncanxyz thanks for opening this PR! I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

Lms24 · 2023-09-08T07:47:17Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


well I guess there's precedence for handling this stuff like this in a general package of ours 😅

the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

Duncanxyz · 2023-09-12T07:19:05Z

I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I agree, this is not an elegant solution. Perhaps in the future, we can implement it through a plugin approach, where additional handling can be injected when referencing framework-specific packages (e.g., @sentry/vue).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

I took the naming reference from @sentry/vue. The _isVue (vue2) and __isVue (vue3) properties are only used to determine if it's a Vue instance, while there are other Vue object type checks like __v_isRef, __v_isReactive, and __v_isVNode. However, the current issue usually occurs only on Vue instance objects.

My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2. After your reminder, I finded that Vue 3 had similar issues and handling before (#4743, #5916, #6014), which essentially were caused by accessing illegal properties of the Vue instance during the rendering process, and warning in Vue's DEV mode. I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

Lms24

Thank you for explaining!

Perhaps in the future, we can implement it through a plugin approach

Maybe, yes - good idea! But for now, this is fine.

However, the current issue usually occurs only on Vue instance objects.
My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

No, after reading your explanations, I think it's fine to keep it as-is.

I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

So just to confirm before we ✅ , this PR currently fixes an issue that's only present in Vue 2 and Vue 3 is not affected by this PR? Then we're good :)

…eadcrumb 1. Preserve the original behavior of console. 2. Centralize special handling for Vue in the utils module.

Duncanxyz · 2023-09-12T10:41:22Z

#8981 (comment)
I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2.

I made a mistake; Vue 3 also has issues, just with different colors 😅. The code I just submitted includes compatibility optimizations for both Vue 2 and Vue 3.

vue2:

vue3:

Lms24

Thank you for reworking this! I think this looks good for now. In case we run into problems we can always revisit.

AbhiPrasad · 2023-09-08T12:36:52Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24 · 2023-09-13T06:54:34Z

@Duncanxyz this will go out in version 7.69.0 in the next couple of hours. Thanks again!

The isVueViewModel() and getVueInternalName() functions from is.ts and stacktrace.ts were only called from two sites: normalize.ts (stringifyValue) and string.ts (safeJoin). Inlining the checks directly at these call sites allows tree-shaking to eliminate the standalone function definitions from bundles that pull in normalize/string but not is.ts for other reasons. Uses the `in` operator instead of `as any` casts to satisfy the linter's no-explicit-any / no-unsafe-member-access rules. The Vue check prevents infinite console warning loops when stringifying Vue 2/3 ViewModel instances or VNodes (see #8981). Saves ~15 bytes gzipped on the base browser bundle. Co-Authored-By: Claude claude@anthropic.com

Duncanxyz · 2023-09-08T02:46:50Z

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

If you've added code that should be tested, please add tests.
Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

close#8980

Lms24

Hi @Duncanxyz thanks for opening this PR! I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

Lms24 · 2023-09-08T07:47:17Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


well I guess there's precedence for handling this stuff like this in a general package of ours 😅

the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

Duncanxyz · 2023-09-12T07:19:05Z

I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I agree, this is not an elegant solution. Perhaps in the future, we can implement it through a plugin approach, where additional handling can be injected when referencing framework-specific packages (e.g., @sentry/vue).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

I took the naming reference from @sentry/vue. The _isVue (vue2) and __isVue (vue3) properties are only used to determine if it's a Vue instance, while there are other Vue object type checks like __v_isRef, __v_isReactive, and __v_isVNode. However, the current issue usually occurs only on Vue instance objects.

My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2. After your reminder, I finded that Vue 3 had similar issues and handling before (#4743, #5916, #6014), which essentially were caused by accessing illegal properties of the Vue instance during the rendering process, and warning in Vue's DEV mode. I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

Lms24

Thank you for explaining!

Perhaps in the future, we can implement it through a plugin approach

Maybe, yes - good idea! But for now, this is fine.

However, the current issue usually occurs only on Vue instance objects.
My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

No, after reading your explanations, I think it's fine to keep it as-is.

I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

So just to confirm before we ✅ , this PR currently fixes an issue that's only present in Vue 2 and Vue 3 is not affected by this PR? Then we're good :)

…eadcrumb 1. Preserve the original behavior of console. 2. Centralize special handling for Vue in the utils module.

Duncanxyz · 2023-09-12T10:41:22Z

#8981 (comment)
I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2.

I made a mistake; Vue 3 also has issues, just with different colors 😅. The code I just submitted includes compatibility optimizations for both Vue 2 and Vue 3.

vue2:

vue3:

Lms24

Thank you for reworking this! I think this looks good for now. In case we run into problems we can always revisit.

AbhiPrasad · 2023-09-08T12:36:52Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24 · 2023-09-13T06:54:34Z

@Duncanxyz this will go out in version 7.69.0 in the next couple of hours. Thanks again!

The isVueViewModel() and getVueInternalName() functions from is.ts and stacktrace.ts were only called from two sites: normalize.ts (stringifyValue) and string.ts (safeJoin). Inlining the checks directly at these call sites allows tree-shaking to eliminate the standalone function definitions from bundles that pull in normalize/string but not is.ts for other reasons. Uses the `in` operator instead of `as any` casts to satisfy the linter's no-explicit-any / no-unsafe-member-access rules. The Vue check prevents infinite console warning loops when stringifying Vue 2/3 ViewModel instances or VNodes (see #8981). Saves ~15 bytes gzipped on the base browser bundle. Co-Authored-By: Claude claude@anthropic.com

Duncanxyz · 2023-09-08T02:46:50Z

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

If you've added code that should be tested, please add tests.
Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

close#8980

Lms24

Hi @Duncanxyz thanks for opening this PR! I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

Lms24 · 2023-09-08T07:47:17Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


well I guess there's precedence for handling this stuff like this in a general package of ours 😅

the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

Duncanxyz · 2023-09-12T07:19:05Z

I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I agree, this is not an elegant solution. Perhaps in the future, we can implement it through a plugin approach, where additional handling can be injected when referencing framework-specific packages (e.g., @sentry/vue).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

I took the naming reference from @sentry/vue. The _isVue (vue2) and __isVue (vue3) properties are only used to determine if it's a Vue instance, while there are other Vue object type checks like __v_isRef, __v_isReactive, and __v_isVNode. However, the current issue usually occurs only on Vue instance objects.

My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2. After your reminder, I finded that Vue 3 had similar issues and handling before (#4743, #5916, #6014), which essentially were caused by accessing illegal properties of the Vue instance during the rendering process, and warning in Vue's DEV mode. I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

Lms24

Thank you for explaining!

Perhaps in the future, we can implement it through a plugin approach

Maybe, yes - good idea! But for now, this is fine.

However, the current issue usually occurs only on Vue instance objects.
My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

No, after reading your explanations, I think it's fine to keep it as-is.

I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

So just to confirm before we ✅ , this PR currently fixes an issue that's only present in Vue 2 and Vue 3 is not affected by this PR? Then we're good :)

…eadcrumb 1. Preserve the original behavior of console. 2. Centralize special handling for Vue in the utils module.

Duncanxyz · 2023-09-12T10:41:22Z

#8981 (comment)
I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2.

I made a mistake; Vue 3 also has issues, just with different colors 😅. The code I just submitted includes compatibility optimizations for both Vue 2 and Vue 3.

vue2:

vue3:

Lms24

Thank you for reworking this! I think this looks good for now. In case we run into problems we can always revisit.

AbhiPrasad · 2023-09-08T12:36:52Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24 · 2023-09-13T06:54:34Z

@Duncanxyz this will go out in version 7.69.0 in the next couple of hours. Thanks again!

The isVueViewModel() and getVueInternalName() functions from is.ts and stacktrace.ts were only called from two sites: normalize.ts (stringifyValue) and string.ts (safeJoin). Inlining the checks directly at these call sites allows tree-shaking to eliminate the standalone function definitions from bundles that pull in normalize/string but not is.ts for other reasons. Uses the `in` operator instead of `as any` casts to satisfy the linter's no-explicit-any / no-unsafe-member-access rules. The Vue check prevents infinite console warning loops when stringifying Vue 2/3 ViewModel instances or VNodes (see #8981). Saves ~15 bytes gzipped on the base browser bundle. Co-Authored-By: Claude claude@anthropic.com

Duncanxyz · 2023-09-08T02:46:50Z

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

If you've added code that should be tested, please add tests.
Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

close#8980

Lms24

Hi @Duncanxyz thanks for opening this PR! I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

Lms24 · 2023-09-08T07:47:17Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


well I guess there's precedence for handling this stuff like this in a general package of ours 😅

the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

Duncanxyz · 2023-09-12T07:19:05Z

I'm not too happy about including framework-specific edge cases in a general package but I think there's no way around it. Also, we did this before as we can see in the code (and in a nother place for Vue iirc).

I agree, this is not an elegant solution. Perhaps in the future, we can implement it through a plugin approach, where additional handling can be injected when referencing framework-specific packages (e.g., @sentry/vue).

I have an important question though: Is there a chance that other objects than VueViewModel might unnecessarily be normalized here? Can other Vue objects have the same _isVue flag? In case yes, maybe it's still fine to normalize them but we should probably change the string to something more generic like "[VueObject]". If this is not possible, let's leave it as is.

I took the naming reference from @sentry/vue. The _isVue (vue2) and __isVue (vue3) properties are only used to determine if it's a Vue instance, while there are other Vue object type checks like __v_isRef, __v_isReactive, and __v_isVNode. However, the current issue usually occurs only on Vue instance objects.

My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

One more question: Have you tested this only with Vue 2 or also with Vue 3? I just want to avoid this fix having a negative impact on Vue 3, given that it's the version that's actually supported and not EOL.

I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2. After your reminder, I finded that Vue 3 had similar issues and handling before (#4743, #5916, #6014), which essentially were caused by accessing illegal properties of the Vue instance during the rendering process, and warning in Vue's DEV mode. I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

Lms24

Thank you for explaining!

Perhaps in the future, we can implement it through a plugin approach

Maybe, yes - good idea! But for now, this is fine.

However, the current issue usually occurs only on Vue instance objects.
My experience with naming might not be extensive enough, so do you have any suggestions regarding this?

No, after reading your explanations, I think it's fine to keep it as-is.

I will make changes to the code later to ensure compatibility with both Vue 2 and Vue 3.

So just to confirm before we ✅ , this PR currently fixes an issue that's only present in Vue 2 and Vue 3 is not affected by this PR? Then we're good :)

…eadcrumb 1. Preserve the original behavior of console. 2. Centralize special handling for Vue in the utils module.

Duncanxyz · 2023-09-12T10:41:22Z

#8981 (comment)
I have tested both Vue 2 and Vue 3, but the issue only occurs in Vue 2.

I made a mistake; Vue 3 also has issues, just with different colors 😅. The code I just submitted includes compatibility optimizations for both Vue 2 and Vue 3.

vue2:

vue3:

Lms24

Thank you for reworking this! I think this looks good for now. In case we run into problems we can always revisit.

AbhiPrasad · 2023-09-08T12:36:52Z

+
 // React's SyntheticEvent thingy
 if (isSyntheticEvent(value)) {
 return '[SyntheticEvent]';


the tricky thing is that some people end up just using @sentry/browser even when using a framework like React or Vue.
but I think we should re-examine this in v8 and see if we can somehow inject in framework specific processing.

Lms24 · 2023-09-13T06:54:34Z

@Duncanxyz this will go out in version 7.69.0 in the next couple of hours. Thanks again!

The isVueViewModel() and getVueInternalName() functions from is.ts and stacktrace.ts were only called from two sites: normalize.ts (stringifyValue) and string.ts (safeJoin). Inlining the checks directly at these call sites allows tree-shaking to eliminate the standalone function definitions from bundles that pull in normalize/string but not is.ts for other reasons. Uses the `in` operator instead of `as any` casts to satisfy the linter's no-explicit-any / no-unsafe-member-access rules. The Vue check prevents infinite console warning loops when stringifying Vue 2/3 ViewModel instances or VNodes (see #8981). Saves ~15 bytes gzipped on the base browser bundle. Co-Authored-By: Claude claude@anthropic.com

fix(utils): Prevent iterating over VueViewModel
45f9f4c

Lms24 reviewed Sep 8, 2023
View reviewed changes

Lms24 mentioned this pull request Sep 8, 2023
Warning when console logging Vue ViewModel #8980
Closed
3 tasks

Lms24 reviewed Sep 8, 2023
View reviewed changes

Lms24 reviewed Sep 12, 2023
View reviewed changes

Duncanxyz added 3 commits September 12, 2023 18:24

fix(utils): Prevent iterating over VueViewModel fro Vue 3
c92da7a

perf(utils): Optimize special handling arguments for Vue in consoleBr…
ada46f4
…eadcrumb 1. Preserve the original behavior of console. 2. Centralize special handling for Vue in the utils module.

fix(utils): Streamline testing for isVueViewModel
bae8c65

Lms24 approved these changes Sep 12, 2023
View reviewed changes

AbhiPrasad approved these changes Sep 12, 2023
View reviewed changes

Lms24 merged commit 90ee2a4 into getsentry:developSep 13, 2023

Lms24 added a commit that referenced this pull request Sep 13, 2023
add#8981
5dfdf5f

socket-securityBot mentioned this pull request Feb 15, 2026
[Snyk] Security upgrade @nomicfoundation/hardhat-verify from 2.1.3 to 3.0.0 Dustin4444/ens-contracts#14
Open

HazAT mentioned this pull request Mar 17, 2026
refactor(core): Inline Vue ViewModel checks in normalize and safeJoin #19855
Closed

KIM-DONGJU mentioned this pull request Jun 6, 2026
Console breadcrumb serialization invokes getters & DOM traversal on logged objects (regression in 10.55.0: safeJoin now uses stringifyValue instead of String) #21353
Closed
3 tasks