Evan You
Evan You
To clarify, what is the case that is currently **not** working? Can you provide a code sample demonstrating a simplified case of what you intend to do?
I don't think this feature should be supported because: - Real custom elements should not assume or be coupled to the parent framework it is being used in. - Custom...
Looks like a language tool issue? (transferred to language-tools, @johnsoncodehk let me know this should be fixed in core)
My bad, I was looking at `compiler-vapor`, not `runtime-vapor`. Discussed with @edison1105 yesterday and I think we need a bit of restructure: 1. The `@vue/vapor` package is unnecessary. `vue` should...
TypeScript's `defineProps` macro does not properly map to the object version in the case of booleans
FYI, the return type of `defineProps` does take this into account: ```ts interface Props { foo?: boolean } const p = defineProps() // ^ { foo: boolean } p.foo //...
This would technically be a (type) breaking change though, it would break existing apps using `const key: InjectionKey = Symbol();`? This probably needs to be put in a minor release...
Looks like the constraint of not being able to use `const k: InjectionKey = ...` is quite disruptive, but I managed to find out a compatible fix in 321d80758.
I think this specific case should be solved in a more custom-element-specific way, and should also avoid relying on `getCurrentInstance()`. see 5a1a89bd6
I think you misunderstood what I meant - `BuiltIn` should include `Primitive`. This PR shouldn't alter how `Builtin` works. That said my last requested change seems unnecessary, since `UnwrapRefSimple` is...