test: strict type assertion - #15107
Open
KazariAI wants to merge 4 commits into
Open
Conversation
📝 WalkthroughWalkthroughThe pull request upgrades the declaration-test ChangesDeclaration test assertion migration
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages-private/dts-test/component.test-d.ts`:
- Around line 201-204: Replace the boxed Number-based expectAssignable
assertions in the rawBindings checks and the corresponding assertion groups at
the referenced locations with exact expectType assertions using lowercase number
and Ref<number> types. Preserve the optional union for setupD as Ref<number> |
undefined, and update all three affected groups consistently.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 0d7df7f7-bf52-446b-a355-6e78eb5cc066
📒 Files selected for processing (20)
packages-private/dts-test/appDirective.test-d.tspackages-private/dts-test/built.test-d.tspackages-private/dts-test/compiler.test-d.tspackages-private/dts-test/component.test-d.tspackages-private/dts-test/componentInstance.test-d.tsxpackages-private/dts-test/componentTypeExtensions.test-d.tsxpackages-private/dts-test/defineComponent.test-d.tsxpackages-private/dts-test/defineCustomElement.test-d.tspackages-private/dts-test/directives.test-d.tspackages-private/dts-test/extractProps.test-d.tspackages-private/dts-test/functionalComponent.test-d.tsxpackages-private/dts-test/h.test-d.tspackages-private/dts-test/inject.test-d.tspackages-private/dts-test/reactivity.test-d.tspackages-private/dts-test/ref.test-d.tspackages-private/dts-test/scheduler.test-d.tspackages-private/dts-test/setupHelpers.test-d.tspackages-private/dts-test/tsx.test-d.tsxpackages-private/dts-test/utils.d.tspackages-private/dts-test/watch.test-d.ts
@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
requested changes
Jul 21, 2026
edison1105
left a comment
edison1105
left a comment
Member
There was a problem hiding this comment.
The exact-equality helper is a good direction, but this migration currently treats several suspicious existing types as the new contract and removes positive coverage. I verified the full DTS suite at both the PR base and head, then added focused usage checks: mutable models inferred from primitive defaults reject other values, raw-object ComponentInstance results are unsound, and the expectAssignable versions of the generic-ref and local-directive cases pass. Please address the inline issues, restore the removed positive coverage, and add a small sanity test for the helper (1 vs number, any vs number, and readonly vs mutable). It would also be better to retain the documented method-signature defineSlots case unless changing that test scenario is intentional.
KazariAI
force-pushed
the
test/strict-type-assertion
branch
from
July 22, 2026 16:35
cb23eb9 to
a8a0b0f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
expectTyperequire exact type equalityexpectAssignablewhere assignability is intentionalThis pull request was created with assistance from a code agent.
Summary by CodeRabbit
expectTypehelper to enforce type equality, with additional dts test coverage for failure cases.