Should Porffor have node compat? #9
Replies: 1 comment
-
While I would like the idea of compiling my node services to native code I don't think it is the compiler's responsability to support anything further than js/ts itself. It could add support for addons so it could support different runtimes and non-standard features. In my opinion addons should be invoked via import attributes. For example, this should import the corresponding file using the node addon. import {process} from "node:process" with { adapter: "node" }; The node addon would be a separate package from porforr (i.e: @porforr/node-addon) We could also add support for porforr-specific extensions the same way. For example, compile time macros would be a nice compiler feature since macros allow slimming down binaries as we skip adding their code and dependencies. We could access the time the binary was built and the hash of the package_lock.json used to build it with the following code. // build_info.ts | macro
import {createHash} from "node:crypto";
import {readFileSync} from "node:fs";
export const build_date = new Date().toString();
export const package_lock_hash = createHash("sha256").update(readFileSync("./package_lock.json")).digest("hex"); import {build_date, package_lock_hash} from "./build_info.js" with { adapter: "node", type: "macro" }; Importing non-js files would be another use-case for addons. ie: import background_image from "./assets/bg.webp" with { adapter: "image/webp", type: "macro", options: {quality: 80, size: {width: 1920, height: 1080}} }; // background_image is a Buffer containing a compressed and resized image generated by the image/webp addon Macros would also enable interop between code meant for otherwise non-compatible runtimes. |
Beta Was this translation helpful? Give feedback.
-
Commonly used Node-y globals like
process
(egprocess.stdout.write
,process.versions.xxxxx
)Beta Was this translation helpful? Give feedback.
All reactions