-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Treat {}
in T = {}
as any
in JS files
#19977
Treat {}
in T = {}
as any
in JS files
#19977
Conversation
@@ -6454,7 +6454,10 @@ namespace ts { | |||
} | |||
for (let i = numTypeArguments; i < numTypeParameters; i++) { | |||
const mapper = createTypeMapper(typeParameters, typeArguments); | |||
const defaultType = getDefaultFromTypeParameter(typeParameters[i]); | |||
let defaultType = getDefaultFromTypeParameter(typeParameters[i]); | |||
if (defaultType && isTypeIdenticalTo(defaultType, emptyObjectType) && isJavaScriptImplicitAny) { |
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.
would emptyTypeLiteralType
equality check do the trick?
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.
Any {}
which has an alias symbol (like in react
) would defeat that. IE,
type InternalMembers = {}
export class ComponentBase<P = InternalMembers> {}
@mhegazy I know I've already merged, but as an improvement, should this production of |
i guess we should flag them all for consistency... that applies to |
This is mostly for cases like
react
, where the component type is defined with restrictive default props of{}
, which while great for TS consumers, makes things difficult for JS users, and makes consuming JS react components inside TS difficult.Fixes #19971