You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a follow-up to #2501 and #3110. I do not believe the XRFrame workaround introduced in #3052 is working as intended.
It seems that TypeScript is evaluating the _XRFrame conditional type at declaration emit time, which results in emitting THREE.XRFrame in the declaration files instead of emitting _XRFrame. This causes errors for users with a @types/three version that does not contain THREE.XRFrame.
Is there a way we can prevent TS from evaluating and unfolding the type? I believe we still use older three types for testing. Noticed the same issues when using an updated version and/or testing ConstructorParameters<typeof THREE.WebGLRenderTarget>[2] for feature detection.
It seems like this is happening when an exported value is not explicitly annotated with a type declaration. Making sure that exported values that reference _XRFrame are explicitly annotated as they will appear in the emitted declaration file seems to fix it. #3196 applies those changes.
This is a follow-up to #2501 and #3110. I do not believe the XRFrame workaround introduced in #3052 is working as intended.
It seems that TypeScript is evaluating the
_XRFrame
conditional type at declaration emit time, which results in emittingTHREE.XRFrame
in the declaration files instead of emitting_XRFrame
. This causes errors for users with a@types/three
version that does not containTHREE.XRFrame
.Here are the errors I get when type-checking:
The text was updated successfully, but these errors were encountered: