A wasm port - for better js/html5 engines support and editor debugging

[blurymind]

Is your feature request related to a problem? Please describe.

YarnEditor's playtest feature is currently using bondagejs, which is far behind what yarnSpinner can do in terms of syntax and has a completely different codebase. Unfortunately YarnEditor as a PWA/electron app has no other way to playtest/debug yarn files with newer syntax capabilities. Bondage would crash at any newer syntax usage and when there is an actual error in the file - bondagejs will not give good hint where it occurred or why.

Describe the solution you'd like

I was recently able to add support for parsing and syntax highlighing of ink files. Ink's compiler is written in C#, however someone made a wasm port, which enabled me to use it directly in the browser.
(inklecate is the compiler, inkjs is the parser)
https://github.com/inkle/ink-library
https://github.com/furkleindustries/inklecate-wasm

Because inklecate compiles the entire file to json before giving it to inkjs, it does all the heavy lifting in terms of logic and syntax - leaving much less complexity to deal with for inkjs. As a result ink has many more parser than yarn does imo.

One of the devs describes here why they decided to split the complexity between parser and compiler by having two files (ink file for editing and ink json file for the game)
https://www.youtube.com/watch?v=KYBf6Ko1I2k

Their compiler+parser combo is vastly superior to what we currently have with bondagejs, becase it will catch errors upon playtesting the file or when you export it. It gives better error reporting and has much stronger support for the ink syntax than bondagejs has for yarn syntax.

If we can get yarnSpinner-wasm port, I will be able to integrate it similar to the ink one and give the editor much greater support for its own main file type!

Describe alternatives you've considered

One alternative is to hire a developer to bring the bondagejs upto speed with yarnspinner, but having to maintain two codebases is no fun at all. I am not sure of what other things can be done to get it to run in a web-browser, but perhaps having a nodejs server running its linux version could be an option too - you would then still have to write some sort of an api for it though

Additional context