Support for Bun

[pekeler]

Would be great if https://bun.sh would be supported as alternative to Node/Deno.

[jamesdiacono]

Bun seems like a really bad idea to me. Do you actually use it? I am hesitant to support a runtime that is doomed.

[jamesdiacono]

Regardless, this will not be possible until Bun supports network imports. Pending oven-sh/bun#38.

Even if Replete will not support Bun out of the box, I intend to extend the interface of Replete's run.js to accept a custom list of REPLs. That way a Bun REPL could be written in userland.

[pekeler]

Yes, we're using bun. It has its shortcomings but we like the runtime performance and speed of their dev team. Feels a bit weird to install deno just for Replete.

[jamesdiacono]

I'd just like to clarify what you are requesting.

It's important to understand that Replete does not run as a single process. Rather, there is a "master" process controlling several "padawan" processes, one for each REPL environment:

   +------------------------------------------+
   |                                          |
   |               Your program               |
   |         (such as a text editor)          |
   |                                          |
   +----------------+-------------------------+
                    |        ^
                    |        |
   Command messages |        | Result messages
                    |        |
                    V        |
+----------------------------+--------------------+
|                                                 |
|         Replete (deno or node process)          |
|                                                 |
+---------+----------------+--------------+-------+
          |                |              |
          v                v              v
+---------------+ +---------------+ +--------------+
|Browser padawan| |Node.js padawan| | Deno padawan |
|(browser tab)  | |(node process) | |(deno process)|
+---------------+ +---------------+ +--------------+

The code for the master process was originally written to run on Node.js. Later, I discovered that the same code ran on Deno, thanks to Deno's excellent Node.js compatibility layer. Deno, unlike Node.js, is capable of loading code directly over the network, removing the most complicated step of Replete's installation, so it became the preferred runtime. As you rightly point out, this convenience came at a cost: a dependency on Deno.

The only way the master can run in a Bun process is if Bun implements the required Node.js APIs.

Now, the padawans. Obviously Deno code must be evaluated in a Deno process, and Node.js code in a Node.js process. But because the interface between master and padawan is loose, any combination of master and padawan is allowed. For example, the following configurations all work:

• a Node.js master and Deno padawan
• a Deno master and a Node.js padawan
• a Deno master and Deno padawan

It is also possible to disable REPLs that are not required, simply by omitting the --which_node or --which_deno arguments.

I am optimistic that I can write a Bun padawan. But unless Bun's Node.js compatibility layer is sufficiently comprehensive, the dependency on Deno or Node.js for the master process will remain.

Does your team have Node.js installed? If so, it should be possible for you to avoid installing Deno whilst still using Replete to evaluate Bun code.

[jamesdiacono]

It turns out Bun's Node.js compatibility is good enough to run Bun, Node.js, and Deno REPLs, but not good enough to run the browser REPL. (This call to socket.write seems to do nothing, I've filed a bug with Bun.)

You should now be able to use Replete without Deno or Node.js installed. You can try it out by cloning the Replete repository, installing the latest VSCode extension, and placing the following replete.json in your project root:

{
    "command": [
        "/path/to/bun",
        "run",
        "/path/to/replete.js",
        "--browser_port=9325",
        "--bun_debugger_port=7378"
    ]
}

Providing a debugging port is optional, but I find it comes in handy.