vm: TypeError thrown instead of ReferenceError when a Proxy is the vm context
まだ誰も着手していません。
- 主要言語
- JavaScript
- スター
- 122k
- フォーク
- 37.3k
- 平均マージ
- 4日 2時間
- マージ済み PR(30日)
- 283
説明
Version
v22.7.0
Platform
Microsoft Windows NT 10.0.22631.0 x64
Subsystem
vm
What steps will reproduce the bug?
"use strict";
const vm = require("vm");
const context = vm.createContext({
__proto__: new Proxy({}, {
get(target, property, receiver) {
return Reflect.get(target, property, receiver);
}
})
});
vm.runInContext("thisFunctionDoesNotExist()", context);
Output:
How often does it reproduce? Is there a required condition?
Always.
What is the expected behavior? Why is that the expected behavior?
If I instead do
const context = vm.createContext({
__proto__: new Proxy({}, {})
});
vm.runInContext("thisFunctionDoesNotExist()", context);
or simply
const context = vm.createContext({});
vm.runInContext("thisFunctionDoesNotExist()", context);
then I get the expected output:
$ node test.js
evalmachine.<anonymous>:1
thisFunctionDoesNotExist()
^
ReferenceError: thisFunctionDoesNotExist is not defined
at evalmachine.<anonymous>:1:1
at Script.runInContext (node:vm:148:12)
at Object.runInContext (node:vm:300:6)
What do you see instead?
evalmachine.<anonymous>:1
thisFunctionDoesNotExist()
^
TypeError: thisFunctionDoesNotExist is not a function
at evalmachine.<anonymous>:1:1
at Script.runInContext (node:vm:148:12)
at Object.runInContext (node:vm:300:6)
at Object.<anonymous> (C:\Users\d\OneDrive - domenic.me\Code\GitHub\jsdom\jsdom\test.js:31:4)
at Module._compile (node:internal/modules/cjs/loader:1546:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1691:10)
at Module.load (node:internal/modules/cjs/loader:1317:32)
at Module._load (node:internal/modules/cjs/loader:1127:12)
at TracingChannel.traceSync (node:diagnostics_channel:315:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:217:24)
Node.js v22.7.0
Additional information
I am not 100% sure this is a vm bug. It may be a fundamental limitation of Proxy and the complicated ECMAScript spec rules governing ReferenceError vs. TypeError. But I am pretty sure this is a vm limitation instead:
- Browsers manage to give a ReferenceError here
- Browsers have something very similar to proxies (the WindowProperties object) as part of their global object
- I can't see anything in the spec for WindowProperties that cannot be emulated by a Proxy.
This is blocking jsdom from passing the web platform test window-runtime-error.html once I implement the WindowProperties object (https://github.com/jsdom/jsdom/pull/3765).
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、issue にある最小の vm.createContext と vm.runInContext の再現コードを実行し、Proxy の各バリアントと通常のコンテキストを比較します。互換性の基準として、リンクされた window-runtime-error.html テストを使用します。Proxy ベースのコンテキストが、ブラウザーおよび Proxy を使用しないケースと同様に、存在しない関数に対して ReferenceError を報告すれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- javascript, nodejs
- 領域
- backend
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 静か
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 45/100