vm: TypeError thrown instead of ReferenceError when a Proxy is the vm context
Personne n'a encore pris cette issue.
- Langage dominant
- JavaScript
- Étoiles
- 122k
- Forks
- 37.3k
- Merge moyen
- 4 j 2 h
- PR mergées (30 j)
- 283
Description
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).
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par exécuter le reproducteur minimal vm.createContext et vm.runInContext de l’issue, en comparant les variantes de Proxy avec le contexte simple. Utilisez le test window-runtime-error.html lié comme cible de compatibilité ; c’est terminé lorsque le contexte basé sur Proxy signale un ReferenceError pour la fonction manquante, comme les navigateurs et les cas sans Proxy.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- javascript, nodejs
- Domaine
- backend
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Calme
- Clarté
- Plutôt claire
- Accessibilité débutants
- 45/100