For every PureScript file/module the compiler creates a single file (you can find them in
You can also use other backends of the PureScript compiler. Then PureScript will produce a different output language (e.g. C) that can then use the specific module/import format of this language. It is also being discussed to use ES modules as an output format of the JS backend as module bundlers and Node.js now support ES modules as well.
The PureScript compiler does not need Node.js as it is written in Haskell. But the REPL compiles your expressions into JS and evaluates them in Node.js. Not all expressions are turned into JS code, e.g. the type system is obviously not part of the output. I am not sure if the backend of the REPL can be changed or if it simply uses the one your PS compiler uses.
Another thing to consider is the FFI. If a library makes use of the FFI, the FFI code obviously needs to be written in the compiler target language. And not only that, the FFI might make use of global variables that are only available in a specific runtime. The PureScript browser libraries bridge to JS code that uses DOM functions that are only available in the browser. Similarly a http server library might make use of the
http module from Node.js and can only be used inside of Node.
Now there are a few use-cases where you might not need Node.js in your toolchain to create (and run) your build. E.g. when you are targeting a non-JS backend or when you just want to produce output files in CI (or a Docker multistage build).
Deno is not a JS runtime but a TypeScript runtime. While they recently made the decision to write internal modules in JS, I think the compiler would still have to output TS. All JS should be valid TS but there might still be type errors because the TS compiler is not able to correctly infer all types. So making PureScript run on deno might not be a simple task for this reason and all the reasons mentioned above.