There's a small issue for opalopal as of now which regards loading of WASM modules - they can be only loaded async (at least in Chromium). I have a plan to support such workflow, but it will take some time.

Other than that, before we flip the default, we will also have to check regressions in source maps.

So what's the current status of using Prism parser in Opal?
Basically I want browser based REPL that uses Prism WASM.

@davispuh This PR is mostly about experimenting with Prism to work under MRI. And it mostly works.

We have a long term goal to migrate from whitequark/parser to prism, but there are multiple issues as of now:

• As I mentioned above, we have to streamline WASM loading. This process has recently stalled, but I plan to go back to it.
  • Not that it's impossible with the current codebase, the problem is that you would have to use await APIs (and implement them yourself; perhaps using https://github.com/interscript/opal-webassembly which may be outdated as of now), so it would not really integrate well with eval and friends.
• The prism WASM module is quite large IIRC. Much larger than whitequark/parser compiled using Opal to JS (which is what we do whenever you do require "opal-parser")
• Since the last supported Ruby release, there haven't been many syntax changes, so for many cases it's enough

My bad, I didn't know it had gotten so big. I've lowered its size now ruby/prism#3824 and it could probably get quite a bit smaller if I'm honest. How big is the built whitequark/parser? I can aim to be smaller than that.

@davispuh Is https://github.com/kateinoigakukun/irb.wasm what you're looking for? That's kind of orthogonal to this PR, which is more about supporting eval.

@kddnewton I think you managed it :). I have tried to isolate Opal-compiled parser (with no other parts of Opal, ie. compiler):

[user@localhost opal]$ bin/opal -sopal/rewriter -ropal/parser -e '#' -Oc --no-source-map | wc -c
1313404
[user@localhost opal]$ bin/opal -sopal/rewriter -ropal/parser -e '#' -Oc --no-source-map | npx terser -cm | wc -c
862924
[user@localhost opal]$ 

The second number is what we should compare against, since most of the time we want to ship Opal-generated code minified.

Oh yeah nice, we're now < half that size.

Is that including the support code for serialization?

Yes! I just added the flags for ignoring the other optional features like JSON support/pack support/etc.