Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review infoConfiguration used: defaults Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdded a guard in the resolver to use Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
Deploying vue-i18n-next with
|
| Latest commit: |
9435920
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://d2b3c959.vue-i18n-next.pages.dev |
| Branch Preview URL: | https://fix-1838.vue-i18n-next.pages.dev |
Size ReportBundles
Usages
|
@intlify/core
@intlify/core-base
@intlify/devtools-types
@intlify/message-compiler
petite-vue-i18n
@intlify/shared
vue-i18n
@intlify/vue-i18n-core
commit: |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/core-base/src/resolver.ts (1)
299-301:⚠️ Potential issue | 🟠 Major
resolveWithKeyValuestill exposes the same prototype-collision bug this PR fixes inresolveValue.
obj[path]is accessed without anhasOwnguard, so a path liketoStringorhasOwnPropertyon an empty object returns the prototype method rather thannull. This makes the two exported resolvers inconsistent in their prototype-safety guarantees.🛡️ Proposed fix
export function resolveWithKeyValue(obj: unknown, path: Path): PathValue { - return isObject(obj) ? obj[path] : null + return isObject(obj) && hasOwn(obj as object, path) ? obj[path] : null }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core-base/src/resolver.ts` around lines 299 - 301, resolveWithKeyValue exposes a prototype-collision bug because it reads obj[path] without checking ownership; update resolveWithKeyValue to mirror resolveValue's prototype-safety by first verifying the key is an own property (e.g., use Object.prototype.hasOwnProperty.call(obj, path) or the existing hasOwn util) and only then return obj[path], otherwise return null so that special keys like "toString" or "hasOwnProperty" on plain objects do not return prototype methods.
🧹 Nitpick comments (1)
packages/core-base/test/resolver.test.ts (1)
136-167: Good coverage — note the correctness of__proto__fixture depends on computed-property notation.
{ [k]: 'hi' }(computed) correctly creates an own property named__proto__, unlike{ __proto__: 'hi' }(shorthand literal) which sets the prototype. The tests are correct as written, but this distinction is fragile: if a future maintainer copies the fixture and switches to shorthand notation, the__proto__cases would silently change behavior. A brief comment would prevent that.📝 Suggested comment
const builtins = [ 'constructor', 'hasOwnProperty', 'isPrototypeOf', 'propertyIsEnumerable', 'toLocaleString', 'toString', 'valueOf', - '__proto__' + '__proto__' // must stay as computed property [k] in fixtures, not shorthand literal ]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core-base/test/resolver.test.ts` around lines 136 - 167, Add a brief explanatory comment in the test 'Object.prototype built-in key paths (issue `#1838`)' next to the builtins array or each fixture to warn that the __proto__ case relies on computed-property notation ({ [k]: 'hi' }) to create an own property; explicitly state that using shorthand literal ({ __proto__: 'hi' }) would mutate the prototype and change behavior of resolveValue, so maintainers must keep the computed form when testing resolveValue with '__proto__'.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@packages/core-base/src/resolver.ts`:
- Around line 299-301: resolveWithKeyValue exposes a prototype-collision bug
because it reads obj[path] without checking ownership; update
resolveWithKeyValue to mirror resolveValue's prototype-safety by first verifying
the key is an own property (e.g., use Object.prototype.hasOwnProperty.call(obj,
path) or the existing hasOwn util) and only then return obj[path], otherwise
return null so that special keys like "toString" or "hasOwnProperty" on plain
objects do not return prototype methods.
---
Nitpick comments:
In `@packages/core-base/test/resolver.test.ts`:
- Around line 136-167: Add a brief explanatory comment in the test
'Object.prototype built-in key paths (issue `#1838`)' next to the builtins array
or each fixture to warn that the __proto__ case relies on computed-property
notation ({ [k]: 'hi' }) to create an own property; explicitly state that using
shorthand literal ({ __proto__: 'hi' }) would mutate the prototype and change
behavior of resolveValue, so maintainers must keep the computed form when
testing resolveValue with '__proto__'.
resolve #1838
related #2098
Summary by CodeRabbit
Bug Fixes
Tests