scriptc turns type-checked TypeScript into native binaries

Type information decides what becomes a native instruction

scriptc reads the same TypeScript you already run on Node, with no annotations and no separate dialect, and it uses the type information in that source to decide what it can turn into native instructions. The type checking is not scriptc's own work. It is the real TypeScript compiler doing the checking, and the result of that check is what makes static compilation possible at all. Code scriptc can't compile is reported at build time with a diagnostic and, where available, a rewrite hint. Reading that boundary in your own code, before you build anything, is the skill this tool actually asks for.

A static build carries no engine, and --dynamic carries one

npm packages compile into the executable with your code, so it doesn't read `node_modules` at runtime. The payoff is portability: it does not need a dependency tree sitting beside it on the target machine. The cost is that a dependency version bump means a rebuild rather than an install on the target. Package support is partial, and the npm dependencies page covers which packages compile and how to check them.

Coverage is the command that shows what will not compile

Before porting anything, there is one command worth running: `scriptc coverage hello.ts`. It shows how much of a program compiles, and the coverage reports page has the details. The project's own framing belongs in the same breath: scriptc is called experimental, and it supports a subset of JavaScript, TypeScript and Node.js APIs, with a limitations page and a Node.js compatibility reference both pointed at before you use it on an existing project.

Executable builds still want a linker and an SDK

Installing the compiler asks for Node.js 24 or later and npm:

$ npm install -g scriptc

After that the split gets interesting. The installed compiler runs natively on supported macOS, Linux and Windows hosts, and native compilation and execution do not require Node.js. Standalone compiler archives are also published on the Releases page for anyone who would rather not install through npm, so Node.js is a dependency of the toolchain rather than of the artifact you ship. It is not the only build-time dependency, though. Executable builds require a platform linker and an SDK or sysroot, which the quickstart page lists as prerequisites and the platform support page expands into host requirements, cross-compilation and WebAssembly. That is the part of setup that changes per machine, and it is where a first build usually stops.

Windows gets a different output name and a different prompt

Every command in the documentation is written for a POSIX shell. On Windows you build `hello.exe` and run it as `.\hello.exe` instead of `./hello`:

$ scriptc build hello.ts -o hello
$ ./hello scriptc
hello, scriptc

The npm example follows the same shape, installing the package first and then building:

$ npm install picocolors
$ scriptc build cli.ts -o cli >/dev/null
$ ./cli
hello from scriptc

So on Windows the documented path is a renamed output plus different invocation syntax, and any wrapper script you write around these commands has to handle both spellings. For a project that names macOS, Linux and Windows as supported hosts, that difference is small, but it is the kind of detail a CI job meets before your code does.

Supported Node APIs compile, and FFI opens the C door

Supported Node.js APIs compile into the native runtime. The worked example is an HTTP server built on `node:http`, using `createServer`, `setHeader`, `end` and `listen`, compiled to a standalone binary and run. Three integration paths are named beyond that, and they are worth knowing exist before you design around them: native program objects, for using compiler output inside an external build; Native FFI, for calling C ABI functions from a compiled program; and WebAssembly modules, for building and embedding WASI modules. An `examples/native-object/` directory exists in the repository for the first of those. None of those pages promises complete coverage, since the supported set is a subset, so look up the exact module you call in the compatibility reference rather than assuming the example generalizes.

The monorepo builds itself with Node 24 and an 8 GB heap

The source tree is a pnpm workspace whose manifest says plainly what building it costs. The top-level `package.json` is `scriptc-monorepo`, marked private, with engines requiring node `>=24.0.0`:

{
  "name": "scriptc-monorepo",
  "private": true,
  "engines": {
    "node": ">=24.0.0"
  },
  "scripts": {
    "build": "pnpm -r --filter \"./packages/*\" run build",
    "build:native-compiler": "node --max-old-space-size=8192 --import tsx scripts/build-native-cli.mts",
    "test": "vitest run",
    "lint": "node docs/scripts/limitations-partials.mjs check && oxlint --deny-warnings packages scripts internal/compatibility/src tests/harness vitest.config.ts",

There is a matching `.node-version` file, an 8 GB heap ceiling on the native compiler build, vitest for tests, oxlint and oxfmt for lint and format, and separate scripts for sandbox tests, benchmarks, a test262 runner. A Dockerfile.sandbox, a benchmarks directory and docs/, internal/, native/, packages/, scripts/ and tests/ sit alongside them, and CONTRIBUTING.md is where source setup is documented. Cadence is fast and the version number explains why: v0.4.5, v0.4.6 and v0.4.7 all landed between 2026-10-25 and 2026-10-31, with the last push on 2026-11-02. Pin a release rather than tracking a pre-1.0 line that moves daily.

Editorial conclusion

scriptc is worth a trial if you ship a TypeScript command line tool or service and want a binary that starts without a Node.js install on the target machine. It is not a drop-in replacement for shipping Node, because the supported API set is a subset, the compiler is labelled experimental at version 0.4.x, and a first build still needs a platform linker and an SDK or sysroot. Before committing, run `scriptc coverage` on the entry point and read the compatibility reference for every module you call. The project is listed as a Vercel Labs experiment and released v0.4.7 on 2026-10-31, so pin that version rather than tracking the moving branch.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes