search

kaleidawave / ezno

A JavaScript compiler and TypeScript checker written in Rust with a focus on static analysis and runtime performance
https://kaleidawave.github.io/posts/introducing-ezno/
MIT License
2.41k stars 45 forks source link

npx ezno repl spews error message #205

Open rotu opened 2 weeks ago

rotu commented 2 weeks ago

npx ezno repl repeatedly prints "Prompt not supported in NodeJS (sync issue)".

It should either:

  1. Fail more gracefully (e.g. print the error message ONCE then exit)
  2. Support Node (e.g. with the readline API)
kaleidawave commented 2 weeks ago

The problem is that the REPL expects a synchronous callback function that prints a prompt and expects string feedback.

In Rust you can write a blocking stdin request and in Deno you can use the web prompt function.

For node, last time I checked I don't think was a blocking stdin function (all callback or Promise based).

I could make it in JS to request to the line checker but the way it currently works is built into the CLI and is a bit of work and duplication logic in JS.

The REPL is an experiment thing so I don't have too much motivation to fix it for this architectural edge case. Thus why it just prints this debug message at the moment.

rotu commented 1 week ago

The problem is that the REPL expects a synchronous callback function that prints a prompt and expects string feedback. In Rust you can write a blocking stdin request and in Deno you can use the web prompt function.

I don't think that it's a reasonable expectation to synchronously wait for user input. In a web browser, for instance, doing so would mean you have to hang the rendering loop and all event handlers.

That said, I don't know if it even makes sense to have a repl coded in WASM. I'd probably reuse node:repl with a custom eval option.

kaleidawave commented 1 week ago

Hmm yes, I think I should just disable the repl subcommand for WASM with something #[cfg(not(target=wasm))].

The web playground is a newer better way to interact with the checker. Maybe could revisit at some point but want to think about the least amount of code and best performant way to support this.

rotu commented 1 week ago

Hmm yes, I think I should just disable the repl subcommand for WASM with something #[cfg(not(target=wasm))].

That works.

The web playground is a newer better way to interact with the checker. Maybe could revisit at some point but want to think about the least amount of code and best performant way to support this.

It's very cool to have a web playground! I don't feel strongly about a command-line repl versus a web playground, but I do love the discoverability and ease of experimentation promised by ezno repl.

Maybe ezno playground should be added to the cli to launch a playground server on localhost?

kaleidawave commented 1 week ago

Might be difficult to spin the playground up locally but opening https://kaleidawave.github.io/ezno/playground/ would be good

rotu commented 1 week ago

Might be difficult to spin the playground up locally but opening https://kaleidawave.github.io/ezno/playground/ would be good

I had a fairly easy time running it locally. Not sure your vision of the future re: cli.js and cli.rs, but in either rust or js, it doesn’t seem too crazy to vite build and host the result in an embedded webserver.

I don’t like linking to the central page because (1) it requires a network connection (2) the web version won’t match the app version in general.

kaleidawave commented 2 days ago

I was thinking that maybe I could abstract the playground as a component out of the page, which would make this easier.

The other problem is that the playground uses the local WASM build. If I was to build it into the CLI it would require compiling the CLI to be compile WASM result -> build the JS library -> embed in CLI (aka the CLI now has 2x the checker code logic, once as *ASM* and again as WASM) -> compile project again. I could put this under a flag and only require it for production builds, but its a little bit too much.

A better way is rather than the running the checker in the browser, it could instead communicate locally with the ASM checker via fetches, etc.

It is a nice idea, be cool to have something like that one day but it is quite low priority atm

rotu commented 2 days ago

I was thinking that maybe I could abstract the playground as a component out of the page, which would make this easier.

I don't think this makes it any easier (but maybe I don't understand what you're suggesting).

embed in CLI (aka the CLI now has 2x the checker code logic, once as ASM and again as WASM)

This is something I didn't properly appreciate. I figured the checker would be compiled to WASM once and that the cli either:

  1. is written in JS and loads the WASM module (as cli.mjs)
  2. is written natively and links to the WASM library
  3. is written against the WASI runtime