EvalError, 'unsafe-eval' when trying to move from webmidi 2.5 to 3.0

[robertmassman]

webmidi.esm.min.js.87
Uncaught (in promise) EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self'".

(node:44479) UnhandledPromiseRejectionWarning: Error: ERR_FAILED (-2) loading 'file:///Users/.../.../.../index.html'
at rejectAndCleanup (node:electron/js2c/browser_init:161:7647)
at EventEmitter.stopLoadingListener (node:electron/js2c/browser_init:161:8022)
at EventEmitter.emit (node:events:390:28)
(Use Electron --trace-warnings ... to show where the warning was created)
(node:44479) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)

webmidi 2.5 works but when I moved to 3.0 the above message is coming up.

Any thoughts on how to resolve the EvalError?

[djipco]

Thanks @robertmassman for reporting this. I looked into it. The error comes from this bit of code that detects whether the current environment is Node.js or not:

/**
 * Indicates whether the execution environment is Node.js (`true`) or not (`false`)
 * @type {boolean}
 */
static get isNode() {
  return new Function("try { return this === global; } catch(e) { return false; }")();
}

This code does not use eval() per se but something that is functionally equivalent. It seems that Electron does not like eval() at all. I tried adding usafe-eval to script-src in the Content-Security-Policy and it did solve the problem (but still threw a warning in the console):

<meta
  http-equiv="Content-Security-Policy"
  content="default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'"
>

Obviously, we need a better solution than that. Oddly, it turns out to be difficult to properly detect the environment the code is running in. I guess I will have to find another way...

I'm going to convert this to an issue so it can be properly tracked.

[djipco]

This discussion will continue in Issue #277.