Tests fail when SES is used

[ljharb]

If https://github.com/ljharb/object.assign/blob/main/test/ses-compat.js#L15 is changed to require('.'), so it runs the tests:

Boolean.prototype.valueOf.call(require('.')(true)) fails (altho Boolean.prototype.valueOf.call(Object.assign(true)) still succeeds).

cc @kumavis

We need to figure out if this is a bug in the entry point, or a bug in SES.

[ljharb]

I'm also seeing issues in es-abstract where the main entry point is returning a non-extensible object.

[kumavis]

so i see this

object.assign on  main [!] is 📦 v4.1.1 via ⬢ v12.16.1 
⇡0% ➜ node test/ses-compat.js 
/home/xyz/Development/object.assign/node_modules/define-properties/index.js:34
		origDefineProperty(object, name, {
		^

[TypeError <Object <Object <[Object: null prototype] {}>>>: Cannot define property getPolyfill, object is not extensible

but its coming from object.assign/node_modules/object.assign which does not have the patch, and seems like a mistake in general

[kumavis]

object.assign on  main [!] is 📦 v4.1.1 via ⬢ v12.16.1 
⇡0% ➜ yarn why object.assign
yarn why v1.22.4
[1/4] Why do we have the module "object.assign"...?
[2/4] Initialising dependency graph...
[3/4] Finding dependency...
[4/4] Calculating file sizes...
=> Found "object.assign@4.1.0"
info Reasons this module exists
   - "es-abstract" depends on it
   - Hoisted from "es-abstract#object.assign"
   - Hoisted from "tape#object.assign"
   - Hoisted from "tape#deep-equal#object.assign"
   - Hoisted from "tape#string.prototype.trim#es-abstract#object.assign"
   - Hoisted from "aud#util.promisify#es-abstract#object.assign"
   - Hoisted from "tape#deep-equal#es-abstract#object.assign"
   - Hoisted from "tape#object-is#es-abstract#object.assign"
   - Hoisted from "es-abstract#string.prototype.trimend#es-abstract#object.assign"
   - Hoisted from "es-abstract#string.prototype.trimstart#es-abstract#object.assign"
   - Hoisted from "safe-publish-latest#yargs#yargs-parser#object.assign"
   - Hoisted from "aud#util.promisify#object.getownpropertydescriptors#es-abstract#object.assign"
   - Hoisted from "tape#deep-equal#regexp.prototype.flags#es-abstract#object.assign"
   - Hoisted from "tape#deep-equal#es-get-iterator#es-abstract#object.assign"
   - Hoisted from "tape#deep-equal#which-typed-array#es-abstract#object.assign"
   - Hoisted from "tape#deep-equal#which-typed-array#is-typed-array#es-abstract#object.assign"
info Disk size without dependencies: "104KB"
info Disk size with unique dependencies: "356KB"
info Disk size with transitive dependencies: "356KB"
info Number of shared dependencies: 4
Done in 0.38s.

object.assign on  main [!] is 📦 v4.1.1 via ⬢ v12.16.1 
⇡0% ➜ cat node_modules/object.assign/package.json| jq .version
"4.1.0"

object.assign on  main [!] is 📦 v4.1.1 via ⬢ v12.16.1 
⇡0% ➜ cat package.json| jq .version 
"4.1.1"

[kumavis]

for Boolean.prototype.valueOf.call(require('.')(true))

the issue is related to GetIntrinsics perhaps inconsistent behavior in handling getters. GetIntrinsic will return the properties value OR its getter. The getter is not called to retrieve the value. For consistency, I think GetIntrinsic should return the property descriptor or it should call the getter and return its value.

Reflect.getOwnPropertyDescriptor(Function.prototype, 'apply')
// no ses:
// --> { value: apply () { ... } }
// with ses
// --> { get: getApply () { ... } }

[ljharb]

I’m seeing that error even with the patched version of object.assign :-/

Does that mean that SES replaces intrinsic data property methods with getters?? The spec requires they be data properties.

[kumavis]

Does that mean that SES replaces intrinsic data property methods with getters

yes, though i think its mostly just to make it read-only. doesnt seem like a requirement.

The spec requires they be data properties.

oh really? could you provide a reference for that? ill bring it up at the next ses-lavamoat call

[ljharb]

i mean, everything that doesn't have a get in front of it is always a data property (https://tc39.es/ecma262/#sec-boolean.prototype.valueof) per https://tc39.es/ecma262/#sec-ecmascript-standard-built-in-objects paragraph 12.

[kumavis]

I see, this get/set pattern is the overwrite mistake workaround

[ljharb]

I'm not sure what the fix can really be here. I suppose I could try to detect SES, but it seems pretty bad to have es-abstract rely on spec violations as a heuristic for when SES is present.

I'm a bit confused tho - the "overwrite mistake" is how the spec works, right? What if there's code relying on it?

[erights]

I'm a bit confused tho - the "overwrite mistake" is how the spec works, right? What if there's code relying on it?

This fix for the override mistake is used by Agoric, Salesforce, MetaMask, Node, Google, Bloomberg and others. AFAIK, none of us have run into a single example of code we wanted to run that relies on the override mistake throwing an exception. However, my impression is that tc39/ecma262#1320 (comment) -- the proposal to fix the override mistake pervasively and unconditionally --- did run into some compat problem. In any case, the total amount of code broken by that will be negligible compared to the code broken by freezing the primordials.

[erights]

However, the concern you raise --- code broken not by the absence of override-mistake behavior, but rather, caused by changing these properties from data to accessor, is a different matter. I would like to understand better the problem you're running into. Can you state a self-contained explanation of why and how your code is hitting this? Thanks.

[ljharb]

I certainly can understand making that tradeoff decision within SES - but it leaves me in a position where some of my packages are incompatible with SES, and also, all of my packages's tests are likely incompatible with SES.

Do you have a suggestion that wouldn't involve either a) hardcoding all expected data properties (or, all expected accessors), or b) hardcoding assumptions about SES?

[erights]

Before making suggestions, I'd like to understand the problem first. Self contained explanation please?

[ljharb]

Sure! I have a GetIntrinsic helper that gets and caches the original (first-run, ofc) value of intrinsics. It supports auto-expanding the dotted notation used in the spec, and when it finds an accessor, it automatically reifies it (calls the get function).

When I do, for example, GetIntrinsic('%Boolean.prototype.valueOf%'), the code expects that data property to be returned - but when it's an accessor, it invokes the get function (hoping to get the actual underlying function value) which throws an error. (that's my best understanding of the problem)