Actually the first step will be to have a Deno-compatible version of Opal.
More precisely, we need a Deno-compatible version of the Node.js module in Opal: https://github.com/opal/opal/blob/master/stdlib/nodejs.rb

Currently this module is using:

• the require directive
• the Node.js fs module
• the Node.js path module
• the Node.js os module
• the Node.js util module
• The glob library
• The unxhr library

(the following are my semi-unrelated ramblings, don't take them too seriously :-) )

Big +1 here from me! After the last couple of years, I became a huge fan of asciidoc language and asciidoctor implementation, and I've been wondering what are the blockers preventing asciidoctor from becoming as ubiquitous as markdown. I think this comes down to the "quality of implementation" issues, and I think deno might be a piece of the solution here. Specifically asciidoctor at the moment seems to be held back by reliance on a single (very mature and exceptional quality) ruby implementation.

One component of the solution here would be a specification (excited that efforts are under way here) and an unopinionated flexible parser (a-la pulldown cmark, writing this in Rust for asciidoc after spec is done is totally on my tood list), which would allow a variety of implementations to make sense of the source documents.

However, unlike markdown, asciidoctor is extensible, and ability to use user-defined code for custom macros or for tweaking the rendering of the document is crucial (I've learned this from asciidoctor-pdf.js, where an ability to define template as a JS function is the killer feature). So having an inert parser is only half of the solution, there also needs to be some scripting environment which supports user-defined code, and which renders the parsed document into HTML or other formats.

I am ready to bet on Deno as a best fit for such scripting environment. It's very young, so the probability that it'll grow big is small . However, as far as scripting engines go, it seems to be way ahead of the rest (cap-based security, built-in dependency management, typed scripting language, access to WASM, high quality of the implementation), so the expected utility of Deno ends up pretty high nonetheless.

And, to circle back to the original issue, running current test suite of the current impl in Deno seems like a step towards the glorious unidoc future I am dreaming about :-)

Now that Deno supports node_modules https://deno.land/manual@v1.15.2/npm_nodejs and https://deno.land/manual@v1.27.0/node I think this maybe more easily accomplished.

Probably, feel free to submit a pull request, I will gladly review it.