Copy the ESM script attribute data when cloning a script component - #9203
Merged
Conversation
3 tasks
Build size reportThis PR changes the size of the minified bundles.
|
mvaligursky
commented
Aug 20, 2026
mvaligursky
left a comment
Contributor
Author
There was a problem hiding this comment.
Automated PR review by Codex (GPT-5).
No actionable issues found.
The shallow object copy is at the correct ownership boundary: it prevents the clone's component data from aliasing the source _attributeDataMap entry while preserving the existing value semantics for attribute payloads, which are subsequently interpreted or cloned according to their schemas. The regression test verifies both identity separation and mutation isolation.
Local verification on the exact head: the full focused ScriptComponent suite passed (89 tests), ESLint passed for both changed files, and git diff --check passed. All current GitHub checks are green.
3 tasks
mvaligursky
force-pushed
the
mv-script-clone-attributes-alias
branch
from
August 21, 2026 09:35
51b9c81 to
2378cba
Compare
`cloneComponent` passed the source component's own `_attributeDataMap` entry straight into the clone's component data, so the clone's `_scriptsData` ends up holding the object the source reads its attribute values back from, and anything writing through one is writing through the other. Nothing mutates it today - `__attributes` only exists on ScriptType instances, which never get an `_attributeDataMap` entry, so the copy loop right below is a no-op for exactly the scripts the map holds data for - but the sharing is not intentional and the loop is one step away from writing into the source. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
mvaligursky
force-pushed
the
mv-script-clone-attributes-alias
branch
from
August 21, 2026 10:09
2378cba to
488aa31
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
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.
Description
Hardening, no user-visible bug today.
cloneComponentpassed the source component's own_attributeDataMapentry straight into the clone's component data:initializeComponentDatathen doescomponent._scriptsData = data.scripts, so the clone's_scriptsDataends up holding the very object the source reads its attribute values back from — anything writing through one writes through the other.Nothing mutates it as things stand:
__attributesonly exists onScriptTypeinstances, and those never get an_attributeDataMapentry (createonly populates the map for non-ScriptTypescripts), so the copy loop is a no-op for exactly the scripts the map holds data for. The two happen to be disjoint, which is what keeps the loop above from writing into the source component. That is a fragile thing to rely on, so copy.Testing
One test in
test/framework/components/script/component.test.mjs, fails onmain: the clone's attribute data is a distinct object, and writing to it does not change the source's.Checklist
🤖 Generated with Claude Code