Repository: deno
Issue: Runtime features to support Quokka.js 
Labels: cli,suggestion

Hi Deno team – firstly, I wanted to say thanks for all your work creating deno. It’s impressive and I am personally looking forward to seeing more community adoption.

Our company creates a couple of popular JavaScript/TypeScript developer tools ([Wallaby.js](https://wallabyjs.com/) and [Quokka.js](https://quokkajs.com/)).

We’ve had a number of our Quokka users asking us to [add support for deno](https://github.com/wallabyjs/quokka/issues/456). If you are not familiar with Quokka, Quokka provides an in-editor scratchpad experience for JavaScript/TypeScript. Runtime values and results are displayed in the IDE right next to your code. Quokka re-executes code as soon as you start typing and provides real-time/immediate feedback. For VS Code alone, Quokka has [733,000+ installations](https://marketplace.visualstudio.com/items?itemName=WallabyJs.quokka-vscode) so we’re keen to add support for deno if we can; this may also help drive adoption of deno, or at the very least would help developers explore the deno runtime.

We spent the last week exploring deno and have identified some blockers to being able to support deno (without us forking the deno code base, which we don’t want to do). We were hoping to work with you so we can get to the point of supporting deno.

The issues we have are:

1. Need to be able to cancel Program unload. (as per your [docs](https://deno.land/manual/runtime/program_lifecycle): […unload event] cannot be cancelled)

Providing real-time feedback while developers are typing means that Quokka has to be fast. To achieve that, we recycle the runner process. The way we do this in node.js is we have a network socket that we unref() before we execute user code and then we ref() it again in process.once('beforeExit'); this stops node.js from terminating between runs. For small projects with no dependencies, this probably doesn’t matter too much, but for larger projects, this will stop the effective use of Quokka.

2. Need to be able to invalidate local files on re-execution

This requirement falls out of (1). If we are recycling the runner process, we need to be able to invalidate any cached local files that may have changed when they are subsequently imported again on a fresh execution.

3. Ability to modify input files prior to execution

This is really the “no public API for compilers” issue (https://github.com/denoland/deno/issues/1739) but we can/have solved lack of API for compilers in other ways in the past that may be lower cost to implementing a full API for compilers with exposed AST, etc. In some other scenarios we have achieved similar functionality by duck-punching fs.readFileSync that is used by node.js when modules are required.

Obviously we appreciate that the paradigm for deno is different to node.js and with the focus on providing a secure by default runtime, we can’t do things the same way so may need first class support for some of our requirements vs. doing things in a hacky way.

---

Finally, we do know that we could get Quokka working with deno today without any of these features, but to do this, we’ll need to make some pretty big internal architectural changes and more importantly, we don’t think our approach will scale for larger projects, at least not until we have a solution to (1) and (2).