Unexpected token error in js-interpreter

[Usaid Khan]

Hello,

I am facing an issue on production but not on local environment.
here is my code which is simple:

let java=`console.log('hello')`

        try {

            myInterpreter = new Interpreter(java);

        } catch (e) {

            console.log(`${e}`)

}

on my local everything is working fine but when I run this code in prod mode I get the following error in catch block:

[Neil Fraser]

JS-Interpreter only supports ES5.  Either provide ES5, or run your ES6+ through Babel.  Here's a demo of the latter:

https://neil.fraser.name/software/JS-Interpreter/demos/babel.html

--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/c44e39c1-37cc-46be-8944-9915ab345957n%40googlegroups.com.

--

Neil Fraser, Switzerland
https://neil.fraser.name

[Christopher Allen]

Niel,

On Wed, 31 May 2023 at 16:26, Neil Fraser <ro...@neil.fraser.name> wrote:

JS-Interpreter only supports ES5.  Either provide ES5, or run your ES6+ through Babel.

It's not clear to me that the code in Usaid's question is being fed to the interpreter; instead, it appears to be the code that creates an Interpreter instance and runs it:

let java=`console.log('hello')`

        try {

            myInterpreter = new Interpreter(java);

        } catch (e) {

            console.log(`${e}`)

}

The code being interpreted appears to be simply "console.log('hello')", which I'm pretty certain is syntactically valid ES5—though I note that neither ES5 nor the JS Interpreter define console.log (or even console), so it will still generate a TypeError when executed.

(Also, there is no way that "let" or template literals would work in the interpreter even locally.)

Moreover, it appears from the second screenshot that in fact the quoted code is already being transpiled to ES5:

Usaid: can you explain what the differences between your local and prod environments are?  Is prod serving the exact same .js files that you have locally?  My best guess would be that the two environments have different build processes, and the prod build process is somehow corrupting the interpreter in the process of minifying it—but that's just a guess.

In any case this is probably not a bug in JS Interpreter, but we would welcome further information that either confirms or contradicts that claim.

Christopher

[Usaid Khan]

Christopher thank you for looking into it.

According to my code, I am just feeding my code to interpreter and not running it. On my local, the output is normal and expected which is in this case is NO OUTPUT because I am not running it. But if I run this code it gives me a typeError: console is not defined  which is also expected as I am not defining console anywhere. But in production mode, without even running it, it gives me syntaxError: unexpected token (62:20).

In Local Mode: I am just running my server with nodemon.

In Production Mode: I am creating build with next build and starting my production mode with next start  

Versions I am using for my next.js app
"react": "18.2.0"

"next": "13.4.3"
"node": "18.16.0"

"js-interpreter": "4.0.0"

[Christopher Allen]

Hi Usaid,

According to my code, I am just feeding my code to interpreter and not running it. On my local, the output is normal and expected which is in this case is NO OUTPUT because I am not running it. But if I run this code it gives me a typeError: console is not defined  which is also expected as I am not defining console anywhere. But in production mode, without even running it, it gives me syntaxError: unexpected token (62:20).

In Local Mode: I am just running my server with nodemon.

In Production Mode: I am creating build with next build and starting my production mode with next start

I'm not familiar with "next build", but it looks like it uses swc for compilation.  Alas I'm not familiar with swc either, but it seems likely that it is the cause of the problem—most probably due to trying to minify it.

It's worth noting that the official acorn+interpreter binary is pre-minified, so does not need to be further minified, and indeed further minification could well be the cause of the failure, as (for example) Acorn contains lookup tables that use keywords as property names that get minified by Closure Compiler in a way that preserves the keyword property names but I don't know enough about swc to know if it provides the same guarantees, and if the lookup table keys are renamed to 'a', 'b', 'c' etc. instead of 'var', 'function', 'break' you can see this would cause syntax errors when parsing.  (Your example doesn't seem to have any keywords in it, but the same principle may well apply to some other part of the parser.)

If you want to pass JS Interpreter through your own minification pipeline then you will either need to configure it to mangle Acorn less and/or start with the uncompressed versions: use acorn.js and interpreter.js instead of acorn_interpreter.js.

"js-interpreter": "4.0.0"

Just to note that the js-interpreter NPM package is not officially supported; you should also try using the latest version from GitHub as it will contain various bugfixes (including security updates) that the maintainer of the NPM package has not yet published.

Best wishes,

Christopher

[Usaid Khan]

Thank you Christopher, I excluded js-interpreter from minimizer during next build and it worked.
Added a single line in next.config.js

//next.config.js const withTM = require('next-transpile-modules')(['js-interpreter']);