Install nanoraster

nanoraster is one JavaScript package that loads a different render artifact per host: Node.js 22.13 or newer, or a browser with WebGPU enabled.

npm install nanoraster

What gets installed

The package selects its render artifact at runtime; nothing needs configuring.

Sixteen platform packages are declared as optional dependencies. Each one declares the os, cpu and (except on armv7) libc it serves, and your package manager installs the single package matching your machine.

The Android packages are experimental: their binaries are built and inspected, and no job renders on an Android device. The armv7 and Windows x86 packages run on the Node.js 22 line, which Node.js 24 and 26 do not publish binaries for. Because platform packages are optional, an install on an unlisted platform succeeds and then fails at render time. Check your host against the compatibility matrix before deploying.

Node.js, browsers and bundlers

The package exports a node condition. Node.js, Bun, a Vite SSR build and a Next.js server build resolve it and reach the native binary. Everything else — a browser bundle from Vite, webpack 5, Rspack or Next.js — resolves the default entry, which imports no Node.js builtin and never references the native loader, so no bundler needs a fs or module fallback.

Keep nanoraster external in a server bundle, so the native binary is loaded from disk instead of being inlined:

export default { serverExternalPackages: ['nanoraster'] };

export default { ssr: { external: ['nanoraster'] } };

Installing for another platform

Building an image for a platform other than the one you install on — a Linux container assembled on macOS, or an arm64 image built on x64 — needs that platform's package instead of the host's. pnpm and Yarn Berry take the set to install:

supportedArchitectures:
  os: [linux]
  cpu: [x64, arm64]
  libc: [glibc, musl]

Yarn classic has no libc selector and installs both Linux packages for an architecture. The loader probes the host at runtime and loads the matching binary either way, so the cost is disk space.

Verify the install

Any static glTF 2.0 binary works as model.glb; the examples in these docs use a 12-tooth spur gear.

import { renderImage } from 'nanoraster';

import { readFile } from 'node:fs/promises';

const glb = Uint8Array.from(await readFile('model.glb'));
const image = await renderImage(glb, { format: 'webp' });

console.log(image.name, image.bytes.length, image.mimeType);

Expected output

render.webp 21208 image/webp

The exact byte count depends on your model; what matters is that a name, a non-zero length and a MIME type print rather than an error.

Bundling for the browser

Browser builds need the WebAssembly binary reachable at runtime. It is published on a dedicated subpath so bundlers can emit it as an asset:

import wasmUrl from 'nanoraster/wasm?url';

The ?url import is tested with Vite, webpack 5 and Rspack; in TypeScript it needs the bundler's ambient types (Vite's vite/client) or a declare module '*?url' declaration. Render in the browser covers the rest, including the WebGPU adapter check.