fix(types): support exact optional public props#14965
Conversation
📝 WalkthroughWalkthroughIntroduces a ChangesexactOptionalPropertyTypes $props fix
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsStopped waiting for pipeline failures after 30000ms. One of your pipelines takes longer than our 30000ms fetch window to run, so review may not consider pipeline-failure results for inline comments if any failures occurred after the fetch window. Increase the timeout if you want to wait longer or run a Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
@vue/compiler-core
@vue/compiler-dom
@vue/compiler-sfc
@vue/compiler-ssr
@vue/reactivity
@vue/runtime-core
@vue/runtime-dom
@vue/server-renderer
@vue/shared
vue
@vue/compat
commit: |
Size ReportBundles
Usages
|
edison1105
left a comment
There was a problem hiding this comment.
Thanks for the fix. I found one remaining exactOptionalPropertyTypes hole around defaulted props.
|
@edison1105 The remaining defaulted-props case was addressed in |
This PR fixes the exactOptionalPropertyTypes regression around defineProps spreads by widening the public $props surface for optional keys while keeping internal toRefs behavior intact. It adds a dedicated exact-optional dts fixture and tsconfig, and passes pnpm test-dts-only.
Fixes #14366.
Summary by CodeRabbit
Tests
exactOptionalPropertyTypesis enabled.Chores / Type Improvements
$propstyping to better preserve optional-prop behavior under strict TypeScript settings, including components with default prop values.