Vm2: TypeError: 'get' sur le proxy: la propriété 'constants' est une propriété de données en lecture seule et non configurable sur la cible du proxy mais le proxy n'a pas renvoyé sa valeur réelle

J'ai également pas mal de problèmes avec les procurations, en particulier avec l'héritage. Je ne sais pas si ces problèmes sont dus à la mise en œuvre ou à une limitation des proxies, mais cela mérite une enquête.

Également rencontré cette erreur. Je ne suis pas assez familier avec les proxys pour comprendre pourquoi le modèle actuel n'est pas correct, mais j'ai pu faire disparaître l'erreur en ajoutant une vérification supplémentaire pour les propriétés non configurables en lecture seule dans Contextify.object.get :

    object: function(object, traps, deepTraps, flags, mock) {
        const proxy = new host.Proxy(object, host.Object.assign({
            get: (target, key, receiver) => {
                if (key === 'vmProxyTarget' && DEBUG) return object;
                if (key === 'isVMProxy') return true;
                if (mock && key in mock) return mock[key];
                if (key === 'constructor') return Object;
                if (key === '__proto__') return Object.prototype;

                                // Added code
                const config = host.Object.getOwnPropertyDescriptor(object, key);
                if (config && config.configurable === false && config.writable === false) {
                    return object[key];
                }

Cela semble suivre l'invariant get décrit par MDN :

La valeur signalée pour une propriété doit être la même que la valeur de la propriété d'objet cible correspondante si la propriété d'objet cible est une propriété de données non accessible en écriture et non configurable.

Mais il me semble que ça briserait le bac à sable

Il suffit de noter que nous avons également rencontré ce problème localement, le changement de code ci-dessus nous permettant de contourner le problème. Notant également que cela s'est produit lors de l'utilisation du module de nœud Google Sheets dans une copie presque exacte de leur guide de démarrage rapide (https://developers.google.com/sheets/api/quickstart/nodejs).

Y a-t-il des mises à jour sur ce problème?

Ce correctif a-t-il un effet sur le problème connu " Il n'est pas possible de définir une classe qui étend la classe mandatée ?" Que voulez-vous dire que cela briserait le sandbox?

Hé, des progrès sur ce problème?
J'ai essayé d'utiliser des bibliothèques comme graceful-fs et j'ai eu la même erreur.

J'ai rencontré cette erreur lorsque j'ai exporté une _class_ ES6 dans le script utilisé pour s'exécuter. c'était ok après l'avoir traduit en
ES5.

Malheureusement, la solution publiée par @mjbvz casse le bac à sable. Je ne pense pas qu'il existe un moyen de résoudre ce problème - si le proxy pour l'objet en lecture seule ne peut rien renvoyer d'autre que la valeur d'origine, alors nous sommes foutus et lancer l'erreur est le seul moyen de sécuriser le bac à sable .

Les idées sont les bienvenues.

Pouvons-nous obtenir un clone dans cette situation?

Le clone n'aide pas - un clone est également une valeur distincte.

Je voulais dire un clone de fs.constants , donc il n'est plus en lecture seule.

Cela permettrait à un bac à sable d'apporter des modifications à l'objet qui pourraient causer des problèmes dans la portée de l'hôte. Vous devez faire très attention à ce que vous envoyez au sandbox car chaque modification apportée à l'objet par le sandbox est également efficace dans le contexte de l'hôte.

Si c'est en lecture seule, avez-vous même besoin d'un proxy pour vérifier les choses?

Y a-t-il une mise à jour sur ce problème?
Je reçois le même problème lors de l'utilisation du module de nœud googleapi ...

Corrigé avec https://github.com/patriksimek/vm2/pull/252.

@XmiliaH Merci! j'apprécie beaucoup. Il fonctionne avec la dernière version.