bug: __proto__ behaves differently from Chrome, Node, and Firefox

[KnorpelSenf]

For some reason, Deno 1.28.2 behaves differently regarding the __proto__ property.

Deno

$ deno
Deno 1.28.2
exit using ctrl+d, ctrl+c, or close()
> let p = '__proto__'
undefined
> let o = {}
undefined
> o
{}
> o[p] = 3
3
> o
{ __proto__: 3 }
>

Node

$ node
Welcome to Node.js v18.9.0.
Type ".help" for more information.
> let p = '__proto__'
undefined
> let o = {}
undefined
> o
{}
> o[p] = 3
3
> o
{}
>

Google Chrome 107.0.5304.110

Firefox 102.5.0esr

[KnorpelSenf]

Before anyone asks: no, this is not related to having a newer version of V8. Here is the same bug with a much older version:

$ deno
Deno 1.12.0
exit using ctrl+d or close()
> let p = '__proto__'
undefined
> let o = {}
undefined
> o
{}
> o[p] = 3
3
> o
{ __proto__: 3 }
> 

$ deno --version 
deno 1.12.0 (release, x86_64-unknown-linux-gnu)
v8 9.2.230.14
typescript 4.3.2

Edit: the same is true for 55da1a2.

[bartlomieju]

It's not a bug, Deno explicitly doesn't have support __proto__, see compat table in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/proto.

Related #16775

[KnorpelSenf]

Fascinating. The background of this issue is that assertEquals from /std fails on Node when compiled by dnt, but it works on Deno. It seems like that is the case because assertEquals converts objects to strings and then compares strings.

This issue will be fixed by #16775. I have opened denoland/dnt#235 on the dnt repo.

[khrj]

Note that #16775 won't completely fix this: The setter will simply warn and fail. Object.setPrototypeOf should be used instead

[dsherret]

See #4324 for more details.