Skip to content

Do not override primordial property by assignment#3109

Merged
jheer merged 3 commits into
vega:masterfrom
erights:master
Mar 16, 2021
Merged

Do not override primordial property by assignment#3109
jheer merged 3 commits into
vega:masterfrom
erights:master

Conversation

@erights

@erights erights commented Mar 5, 2021

Copy link
Copy Markdown
Contributor

By "primordial object" I mean all standard EcmaScript objects that exist before code starts running, like especially Object.prototype. SES and several other systems freeze all JS primordials on initialization. As explained at #3075 , because of the override mistake, on an object that inherits from a primordial object, an attempt to override one of these properties, such as hasOwnProperty, by assignment will fail to do so. (By "override" we mean to create a new own property of the same name on the inheriting object.)

This PR replaces the occurrences we are aware of vega making this mistake directly in its source code.

However, as explained at #3075 the cases that matter are automatically generated somehow by vega itself. The change needs to produce code like that show by the patches additions of https://github.com/Agoric/agoric-sdk/blob/master/patches/vega-util%2B1.16.0.patch which enable vega to work under SES as used by the agoric-sdk monorepo.

@domoritz

domoritz commented Mar 6, 2021

Copy link
Copy Markdown
Member

Thank you for the pull request. Can you remove the compiled files in docs as we compile them during releases?

@erights

erights commented Mar 7, 2021

Copy link
Copy Markdown
Contributor Author

Hi @domoritz I did, so we can proceed with this PR. However, this omits the change that matters most, to the line

exports.hasOwnProperty = has;

This line does not appear anywhere in your sources. I see now that vega does its own code generation, and so must be generating this line. However, I could not figure out where this happens or how to fix it. So I have removed from the PR description that it fixes the
#3075
issue. Instead, that issue remains open. Can you point me at the place in the code generation that puts that assignment statement together? Thanks.

@domoritz

domoritz commented Mar 7, 2021

Copy link
Copy Markdown
Member

I assigned @jheer as he wrote most of the code.

@jheer

jheer commented Mar 8, 2021

Copy link
Copy Markdown
Member

It looks like the remaining issues stem from vega-util/index.js where we name the exports such as hasOwnProperty. One route could be to rename those exports, though that involves a breaking change and thus a major version bump. Alternatively, perhaps there is a way to signal to package bundlers (such as rollup, which Vega uses) to use defineProperty for those exports?

@erights

erights commented Mar 8, 2021

Copy link
Copy Markdown
Contributor Author

Is the export.<stuff> = <stuff>; coming from rollup? That would explain why I couldn't find it in your codegen ;)

@jheer

jheer commented Mar 8, 2021

Copy link
Copy Markdown
Member

Yes, that is the output of rollup.

@erights

erights commented Mar 8, 2021

Copy link
Copy Markdown
Contributor Author

Thanks. In that case, this PR as is addresses the entire vega specific issue. The remaining bug is in rollup. I'll pursue it over there.

Is this PR by itself good? Thanks.

@erights

erights commented Mar 8, 2021

Copy link
Copy Markdown
Contributor Author

This PR would, therefore, close out #3075 . I will file a separate bug with rollup.

@jheer jheer merged commit 80c21b1 into vega:master Mar 16, 2021
@jheer jheer mentioned this pull request Mar 16, 2021
@erights

erights commented Mar 16, 2021

Copy link
Copy Markdown
Contributor Author

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants