fix(utils): Make new non-enumerable properties mutable #4528
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.
There are a few places in the SDK where we add properties to an object in order to store data for internal use. In cases where there's a chance that object might be serialized, we need to make sure the new properties are non-enumerable, which we do with the (appropriately-named) function
addNonEnumerableProperty
.Currently, the non-enumerable properties we add are also immutable, even though nothing requires them to be, simply because that's the default when using
Object.defineProperty()
. This blocks use-cases in which a user might choose to modify an internal property's value in order to change how the SDK behaves. (See the attached issue for an example of such a use-case.)This PR explicitly makes these properties mutable. It also changes the docstring to reflect the fact that the function can be used for more than just setting properties on function objects.
Fixes #4525.