JS-Interpreter
JS-Interpreter copied to clipboard
NeilFraser
Support ES6 and beyond
... I saw the lib, acorn.js's version just 0.4.1 .... If I use the high version ecmascript code , for example :
for (let i of [1, 2, 3]) {
console.log(i)
}
It will throw an error ...
The last version of acorn.js is 7.1.0 ,but Js-Interpreter only 0.x
Too terrible
The limiting factor is not Acorn (though updating it might not be a bad idea anyway), but that JS Intrpreter itself only understands ES5.1. So being able to parse for ... of loops wouldn't help, because the interpreter still wouldn't know how to execute them.
Nevertheless, since no one seems to have opened a "please support ES6" issue yet, I'll repurpose your report accordingly.
Thank you for your answer I try to repackage with [email protected] just now .
Link here: https://github.com/KRISACHAN/acorn_interpreter.bundle.js
I don't know if it's a good idea . :)
Happy Weekend !
I try to repackage with [email protected] just now.
Just make sure you specify the appropriate options to Acorn so that it will parse ES5 only.
@cpcallen Supporting ES6+ features would be awesome, this is the only "deal breaker" for me of using the lib. Is it something you are considering doing?
Is it something you are considering doing?
This is a question for @NeilFraser—but I suspect the answer is no, because this will eventually be part of the roadmap of another project (which is actually funded, unlike this one), so in a few years we will have a much better solution.
In the mean time, I would suggest using an ES6->5 transpiler. I have heard that Babel can do this.
Thanks @cpcallen. Actually my use case for this library is to create a JavaScript "visualiser" (similar to devtools), not sure babel can help with this as it will change that actual code i want to visualise.
Same here, I have tried using source maps to correct this, but they don't seem to come out correctly.
Just to confirm, I have no interest in developing and maintaining an ES6+ version. It would be a step backwards for my projects in that the download times would increase.
However, I recognize that there is a genuine need for ES6+ support in other projects and I'd fully support anyone who wishes to fork the project accordingly.
Sent (awkwardly) from an Android device.
On Wed, 8 Apr 2020, 19:53 KSean222, [email protected] wrote:
Same here, I have tried using source maps to correct this, but they don't seem to come out correctly.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NeilFraser/JS-Interpreter/issues/186#issuecomment-611252033, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB5E4A4JTJ42ZQACWAQUM3RLUE6NANCNFSM4LU5LUOA .
@sag1v https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map Babel can generate source maps when converting to ES5.
https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map Babel can generate source maps when converting to ES5.
Yeah i know, but how do you think it to sync them? Sounds interesting
Is it something you are considering doing?
This is a question for @NeilFraser—but I suspect the answer is no, because this will eventually be part of the roadmap of another project (which is actually funded, unlike this one), so in a few years we will have a much better solution.
In the mean time, I would suggest using an ES6->5 transpiler. I have heard that Babel can do this.
What is the name of the funded project?
What is the name of the funded project?
Code City. But do note: "will eventually be part of the roadmap"—in its present form Code City is actually a less-complete JavaScript implementation than JS Interpreter is.
I'm very interested in this, as it would be useful for creating a client-side step debugger for Theia IDE.
In theory, how much work are we talking to make this happen? Would it require a major re-write of the interpreter? Or is it just adding ES-6 specific features?
@bendavis78: It would be a considerable amount of work. ES6 is quite a bit larger language than ES5.1, and ES2020 is even more so. I don't think it necessarily requires a throw-it-away-and-start-from-scratch rewrite: it could certainly be done incrementally—but by the time it was done very little of the original code base will remain.