Install nanoraster

nanoraster is one JavaScript package. It 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.

The package declares sixteen platform packages as optional dependencies. Each platform package declares the os, cpu, and (except on armv7) libc it serves. Your package manager installs the single package that matches 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. Node.js 24 and 26 do not publish binaries for those platforms. Platform packages are optional, so 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. It 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 loads from disk and the bundler does not inline it:

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

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

Installing for another platform

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

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

Yarn classic has no libc selector, and it 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. Confirm that a name, a non-zero length, and a MIME type print instead of an error.

Bundling for the browser

Browser builds need the WebAssembly binary to be reachable at runtime. The package publishes it on a dedicated subpath, so that 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.