fix: undefined assigned to a prototype-inherited key gets dropped#1262
Merged
mweststrate merged 1 commit intoJul 3, 2026
Merged
Conversation
If an object's prototype has a key set to undefined and you assign undefined to that same key on a draft, immer treats it as a no-op since `prop in state.copy_` walks the prototype chain and finds it "already there." No own property gets created, no patch gets recorded. Swapped that for the has() own-property check that's already used a few lines up for the same purpose, and added a regressions test.
Collaborator
|
Looking good, thanks for noticing and fixing! |
Contributor
|
🎉 This PR is included in version 11.1.10 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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.
Ran into this via #1160. If a draft's prototype has a key sitting at
undefined(a class field with no initializer, or anything made withObject.create), assigningundefinedto that same key on the draft is silently swallowed — no own property shows up on the result and no patch gets generated.The
settrap usesprop in state.copy_to tell "already has this key" apart from "brand new key," butinwalks the prototype chain, so an inherited key looks like it's already there even though it isn't an own property yet. Swapped it for thehas()own-property check that's already used a few lines above for basically the same reason.Added a test in regressions.js that checks both
hasOwnPropertyon the result and the patch that comes out ofproduceWithPatches.