Revisit deno vendoring

[lgalabru]

trafficstars

It looks like the deno team started unbundling their stack. We should explore what is possible with these 2 repos:

• https://github.com/denoland/deno_emit
• https://github.com/denoland/deno_graph

Thanks to this effort, we might be able to get rid of our vendored fork of deno - which would be way healthier. Would resolve https://github.com/hirosystems/clarinet/issues/393

[moodmosaic]

Is the clarinet <> deno embed/integration documented? Perhaps I could look into any existing docs and throw some ideas.

[lgalabru]

Undocumented, unfortunately, but happy to hop on a call if you'd like to have an overview.

[moodmosaic]

Yep, let's document some of this so that it's available for anyone else that might want to dive in.

[moodmosaic]

🏓

[hstove]

I understand that un-vendoring would be a pain, but what about upgrading the base version of Deno? For example, I'd like to write BDD-style tests, but the version of Deno that Clarinet runs doesn't have support for Deno.TestContext.

[moodmosaic]

@hstove, if you're interested in the BDD-style hooks mentioned on that Deno link, perhaps you'll find the work from @LNow and myself in this repo interesting.

[lgalabru]

To be addressed in https://github.com/hirosystems/clarinet/pull/511.