Pegjs: Fügen Sie eine Nicht-Eval-Alternative für die Kompatibilität mit Inhaltssicherheitsrichtlinien hinzu

Bei pegjs sieht das nicht nach einem Problem aus.
Laden Sie Ihre Skripte von einer unsicheren Quelle (http?)

Ich kann dies auf den Protokollen http und https reproduzieren. Es geht um Sicherheitspolitik. Wenn der Code die eval-Funktion verwendet, wird er nicht ausgeführt, der Browser blockiert seine Ausführung
Ich habe einen Workaround dafür, aber es ist nicht sicher.
Weitere Details zur Sicherheitsrichtlinie:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

Ihr Link ist für http-Header. Sie haben die Kontrolle über alle Header, die Sie an Ihren Server senden.

Ja, dieser Header bezieht sich auf Sicherheit, aber welche Anwendung im Jahr 2020 wird nicht an Sicherheit denken. Es ist durchaus üblich, diesen Ansatz in einer modernen Webanwendung zu verwenden.
Ich habe ein bisschen gegoogelt und festgestellt, dass beliebte Bibliotheken dieses Update bereits gemacht haben.
Ich glaube daher nicht, dass viele Anwendungen die Sicherheit in Zukunft ignorieren und geeignete Tools auswählen, die damit vereinbar sind.

Pegjs ist ein Parser-Generator, es ist eine Art separater Art von JS-Libs.
Wie würde JS innerhalb der Grammatik funktionieren, ohne dass eval sie verwendet hätte?

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

Ich glaube nicht, dass das eine gute Lösung für einen Parser-Generator ist. Leistung ist hier schließlich ziemlich wichtig.

Mir fehlt der Kontext in dieser Ausgabe. Kann jemand mit dem Finger auf einen relevanten Code zeigen?

Ich denke, es lohnt sich, eine Nicht- eval Alternative hinzuzufügen, um die Kompatibilität mit der Inhaltssicherheitsrichtlinie zu gewährleisten. wird dies irgendwann vor 0.12 untersuchen, indem es ein weiteres Bundle (möglicherweise mit dem Namen dist/peg.csp.js ) über eine neue Eintragsdatei hinzufügt, die nur von Webpack verwendet wird

Machen Sie es wahrscheinlich nicht nur webpack. Dieses Problem ist nicht webpack-spezifisch, und Webpack ist schnell rückläufig, zugunsten von Rollup und Paket

Ehrlich gesagt gibt es keinen besonderen Grund, eval beizubehalten, wenn eine Alternative angeboten wird. Es ist nicht so, als wäre es irgendwie schneller, wie oben seltsam angedeutet. Ganz im Gegenteil

Dies sollte nicht als not-a-bug . Tatsächlich handelt es sich um einen schwerwiegenden Fehler.