Ship a binary.

Name an output, test the artifact on its target, and optimize only when the measurement asks you to.

Keep the output

The second positional argument is the output path. Release optimization is already the default.

terminal

$ porf app.js app
$ ./app

porf native app.js app is the explicit form of the same command. The result targets the OS and CPU architecture of the build machine.

Tune deliberately

Need	Control	Tradeoff
Smaller release	`-s`	Strips symbols, making post-crash inspection harder.
CPU-specific speed	`--march=native`	The binary may not run on older processors.
Faster build	`--no-flto`	Gives up link-time optimization.
Debug signal	`-d`	Larger, slower artifact with names and logs retained.
Different toolchain	`CC=clang`	Compiler availability becomes part of the build environment.

Define portability correctly

A Porffor executable has no Node.js dependency, but it is not automatically cross-platform. Build once per operating system and architecture you distribute.

Do not copy blind

Before release, exercise the exact artifact on the oldest CPU and operating-system version you promise to support.

Static x64 Linux

For a Linux artifact linked with musl, install Zig and use the dedicated switch.

terminal

$ porf --musl app.js app-linux

Use a release gate

Compare behavior

Run the same input through your reference runtime and the compiled artifact.

Measure the real workload

Record startup, steady-state time, peak memory, and artifact size only if they matter to the product.

Preserve a debug build

Keep a matching unstripped artifact for investigating reports from the release build.