1.Server set header: Content-Security-Policy: default-src https:
This does not look like an issue with pegjs.
Are you loading your scripts from an unsecure source (http?)
I can reproduce this on the http and https protocols. It's all about security policy. If the code uses the eval function, then it will not be executed, the browser will block its execution
I have a workaround for that, but it is not secure.
More details about security policy:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
Your link is for http headers. You are in control of whatever headers you send on your server.
Yes, this header is related to security, but which application in 2020 will not think about security. It's quite a common practice to use this approach in a modern web application.
I googled a bit and noticed that popular libraries have already made this update.
So, I do not think that many applications will ignore security in the future, and select appropriate tools that will be consistent with this.
Pegjs is a parser generator, it is a bit of a separate breed of JS libs,
How would JS inside grammar work without eval
ing it?
I dont think that is a good solution for a parser generator. Performance is pretty important here after all.
I'm missing context in this issue. Can anybody finger-point at piece of relevant code?
I think it's worth adding a non-eval
alternative for Content Security Policy compatibility; will see into this at some point before 0.12 by adding another bundle (maybe named dist/peg.csp.js
) via a new entry file to be consumed by Webpack only
Probably don't make it webpack only. This problem isn't webpack specific, and webpack is rapidly on the decline, in favor of rollup and parcel
Honestly, there's no particular reason to leave eval
in place if any alternative is provided. It's not like it's somehow faster, as oddly suggested above. Quite the opposite
This should not be flagged not-a-bug
. It is, in fact, a severe bug.
Most helpful comment
I think it's worth adding a non-
eval
alternative for Content Security Policy compatibility; will see into this at some point before 0.12 by adding another bundle (maybe nameddist/peg.csp.js
) via a new entry file to be consumed by Webpack only