Pegjs: Ajouter une alternative non-Eval pour la compatibilité avec la politique de sécurité du contenu

Cela ne ressemble pas à un problème avec pegjs.
Chargez-vous vos scripts à partir d'une source non sécurisée (http ?)

Je peux reproduire cela sur les protocoles http et https. Tout est question de politique de sécurité. Si le code utilise la fonction eval, alors il ne sera pas exécuté, le navigateur bloquera son exécution
J'ai une solution de contournement pour cela, mais elle n'est pas sécurisée.
Plus de détails sur la politique de sécurité :
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

Votre lien est pour les en-têtes http. Vous contrôlez les en-têtes que vous envoyez sur votre serveur.

Oui, cet en-tête est lié à la sécurité, mais quelle application en 2020 ne pensera pas à la sécurité. Il est assez courant d'utiliser cette approche dans une application Web moderne.
J'ai un peu cherché sur Google et j'ai remarqué que les bibliothèques populaires ont déjà fait cette mise à jour.
Donc, je ne pense pas que de nombreuses applications ignoreront la sécurité à l'avenir et sélectionneront des outils appropriés qui seront cohérents avec cela.

Pegjs est un générateur d'analyseur, c'est un peu une race distincte de bibliothèques JS,
Comment JS à l'intérieur de la grammaire fonctionnerait-il sans eval ?

Voir : https://github.com/acornjs/acorn/issues/90

Je ne pense pas que ce soit une bonne solution pour un générateur d'analyseur. La performance est assez importante ici après tout.

Je manque de contexte dans ce problème. Quelqu'un peut-il pointer du doigt un morceau de code pertinent ?

Je pense que cela vaut la peine d'ajouter une alternative non eval pour la compatibilité avec la politique de sécurité du contenu ; verra cela à un moment donné avant 0.12 en ajoutant un autre bundle (peut-être nommé dist/peg.csp.js ) via un nouveau fichier d'entrée à utiliser uniquement par Webpack

N'en faites probablement pas uniquement un webpack. Ce problème n'est pas spécifique au webpack, et le webpack est en déclin rapide, en faveur du rollup et du parcel

Honnêtement, il n'y a aucune raison particulière de laisser eval en place si une alternative est proposée. Ce n'est pas comme si c'était plus rapide, comme curieusement suggéré ci-dessus. Plutôt l'inverse

Cela ne doit pas être marqué not-a-bug . C'est, en fait, un bug grave.