refactor(runtime-core): check `props` rather than `propsOptions[0]`

[skirtles-code]

This is minor refactoring of the logic for handling props in PublicInstanceProxyHandlers.get and PublicInstanceProxyHandlers.has, switching it from checking propsOptions[0] to checking props. The new version is simpler and leads to a smaller build.

In Vue 3.0, props could be missing from the props object. Props were only included if they were passed in by the parent or had a default value. The logic in PublicInstanceProxyHandlers couldn't rely on checking props, so it checked propsOptions[0] instead.

That changed in 3.1.0. See #3288 for more details, but props now contains all the props.

Some other notes about what I changed and why...

• The code for set hasn't been changed as that was already using props.
• I did consider adding a check for EMPTY_OBJ (as used for other sources of properties, e.g. data), but props won't be an EMPTY_OBJ by the time this code runs, even for components that don't declare any props.
• propsOptions is populated before props, so there is potentially a timing issue introduced by this change. However, in practice, the only user-facing 'hook' that runs between the population of those two objects is the default function for a prop. The default function doesn't have access to the relevant proxy, so it could only encounter a problem if it called getCurrentInstance().proxy (which it shouldn't be doing anyway) and then did some very strange things with it. I don't think this is a realistic case.
• I've also removed an adjacent comment that seems to be referring to a much older implementation and is no longer relevant.
• The existing tests all pass, but I don't think they're actually testing this specific aspect. I did try to add some extra tests, but it's quite difficult to test because dev builds expose all props via ctx (see exposePropsOnRenderContext in the same file). Even if the logic for props is wrong it still 'works' because they're accessed via ctx instead. If the logic were wrong it would likely only fail in a production build.

Summary by CodeRabbit

• Refactor
  • Simplified property access logic for component instances, improving maintainability without affecting user-facing behavior.

[coderabbitai[bot]]

Walkthrough

Replaced checks against cached propsOptions[0] with direct hasOwn(props, key) checks in the component public instance proxy's get and has traps; removed normalizedProps local variables and updated the has context destructuring to expose props.

Changes

Cohort / File(s)	Change Summary
Runtime core — componentPublicInstance packages/runtime-core/src/componentPublicInstance.ts	Replaced prop-existence checks that used instance.propsOptions[0]/normalizedProps with direct hasOwn(props, key) in get and has traps; updated has context destructure to include props; removed normalizedProps locals.

Sequence Diagram(s)

sequenceDiagram
  participant Proxy as Component Proxy
  participant Instance as Component Instance
  participant Props as instance.props

  rect rgb(230, 245, 255)
    Note over Proxy,Instance: get / has trap flow (new)
  end

  Proxy->>Instance: trap.get(key)
  alt key in data / setupState / ctx
    Instance-->>Proxy: return resolved value
  else check props directly
    Instance->>Props: hasOwn(props, key)?
    alt true
      Props-->>Proxy: return props[key]
    else
      Instance-->>Proxy: fallback lookup / undefined
    end
  end

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Files to focus on: packages/runtime-core/src/componentPublicInstance.ts — verify has/get semantics unchanged for edge cases (scoped keys, proxy caching, accessCache usage).
• Confirm no other callsites rely on propsOptions[0] shape change.

Possibly related PRs

• vuejs/core#13507 — Modifies PublicInstanceProxyHandlers.has similarly to align prop checks in has with get.

Suggested reviewers

• KazariEX
• edison1105

Poem

In the warren of wires I softly tread,
Props checked straight — no path misled.
A tiny hop, a clearer view,
The proxy wakes with logic new.
Rabbit cheers for code made true. 🐇

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely summarizes the main refactoring change: replacing checks on propsOptions[0] with direct props checks.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• [ ] 📝 Generate docstrings

🧪 Generate unit tests (beta)

• [ ] Create PR with unit tests
• [ ] Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e7b0d93389efba38142f50c359e532ef00f05b69 and 55d0702a582308c166257c7ebcc099018a80c6b3.

📒 Files selected for processing (1)

• packages/runtime-core/src/componentPublicInstance.ts (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

packages/runtime-core/src/componentPublicInstance.ts (1)

packages/shared/src/general.ts (2)

• hasOwn (34-37)
• EMPTY_OBJ (3-5)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: test / e2e-test

🔇 Additional comments (2)

packages/runtime-core/src/componentPublicInstance.ts (2)

579-592: Same verification needed for the has trap.

The changes here mirror those in the get trap—replacing propsOptions[0] checks with direct hasOwn(props, key). This maintains consistency between the two handlers, but the same timing and ecosystem concerns from the get trap apply here.

Ensure that the verification of timing and ecosystem failures covers both the get and has traps.

---

457-459: Verify ecosystem CI status and confirm no regressions in production builds.

The change from checking propsOptions[0] to hasOwn(props, key) (commit e7b0d933) appears to be an intentional refactor. Code analysis shows that instance.props is initialized to EMPTY_OBJ, then populated by initProps() before the proxy is created, ensuring the timing sequence is correct.

However, without access to the specific ecosystem failure logs from nuxt, language-tools, and vue-macros, I cannot verify whether those failures are real, resolved, or regressions from this change.

Action needed: Confirm that ecosystem CI has passed or investigate any remaining failures in those projects. If failures exist, check whether they are related to the propsOptions → props change or unrelated issues.

[!TIP]

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions: | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context. Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[pkg-pr-new[bot]]

Open in StackBlitz

@vue/compiler-core

npm i https://pkg.pr.new/@vue/compiler-core@13514

@vue/compiler-dom

npm i https://pkg.pr.new/@vue/compiler-dom@13514

@vue/compiler-sfc

npm i https://pkg.pr.new/@vue/compiler-sfc@13514

@vue/compiler-ssr

npm i https://pkg.pr.new/@vue/compiler-ssr@13514

@vue/reactivity

npm i https://pkg.pr.new/@vue/reactivity@13514

@vue/runtime-core

npm i https://pkg.pr.new/@vue/runtime-core@13514

@vue/runtime-dom

npm i https://pkg.pr.new/@vue/runtime-dom@13514

@vue/server-renderer

npm i https://pkg.pr.new/@vue/server-renderer@13514

@vue/shared

npm i https://pkg.pr.new/@vue/shared@13514

vue

npm i https://pkg.pr.new/vue@13514

@vue/compat

npm i https://pkg.pr.new/@vue/compat@13514

commit: 55d0702

[github-actions[bot]]

Size Report

Bundles

File	Size	Gzip	Brotli
runtime-dom.global.prod.js	103 kB (-44 B)	38.9 kB (-18 B)	35 kB (-46 B)
vue.global.prod.js	161 kB (-44 B)	58.8 kB (-20 B)	52.3 kB (-52 B)

Usages

Name	Size	Gzip	Brotli
createApp (CAPI only)	46.8 kB (-44 B)	18.3 kB (-17 B)	16.8 kB (-14 B)
createApp	55 kB (-44 B)	21.4 kB (-18 B)	19.6 kB (-22 B)
createSSRApp	59.3 kB (-44 B)	23.1 kB (-22 B)	21.1 kB (+2 B)
defineCustomElement	60.6 kB (-44 B)	23.1 kB (-20 B)	21.1 kB (-16 B)
overall	69.3 kB (-44 B)	26.6 kB (-21 B)	24.2 kB (-58 B)

[jh-leong]

/ecosystem-ci run

[vue-bot]

📝 Ran ecosystem CI: Open

suite	result	latest scheduled
nuxt	:x: failure	:white_check_mark: success
language-tools	:x: failure	:white_check_mark: success
quasar	:white_check_mark: success	:x: failure
vue-i18n	:white_check_mark: success	:white_check_mark: success
pinia	:white_check_mark: success	:white_check_mark: success
vant	:white_check_mark: success	:white_check_mark: success
vueuse	:white_check_mark: success	:white_check_mark: success
vitepress	:white_check_mark: success	:white_check_mark: success
router	:white_check_mark: success	:white_check_mark: success
primevue	:white_check_mark: success	:white_check_mark: success
radix-vue	:white_check_mark: success	:white_check_mark: success
vite-plugin-vue	:white_check_mark: success	:white_check_mark: success
vue-macros	:x: failure	:white_check_mark: success
vue-simple-compiler	:white_check_mark: success	:white_check_mark: success
test-utils	:white_check_mark: success	:white_check_mark: success
vuetify	:white_check_mark: success	:white_check_mark: success