Setup

import { defineConfig } from "vite";
import { hem } from "@hem-lang/vite-plugin";

export default defineConfig({
  plugins: [hem()],
});

Register hem() alongside any framework plugin your project uses. It compiles each .hem file to a .ts or .tsx sibling on disk and updates it as you edit. Vite consumes ordinary files rather than virtual modules. Outside Vite, use hem fmt, hem check, hem build, and hem test.

Files end in .hem and compile to .tsx, or to .ts when a file contains no JSX. Hem reads your real tsconfig for module resolution, libraries, JSX, paths, and project membership, then overlays strict, strictNullChecks, and noUncheckedIndexedAccess inside its own no-emit checker. An existing application does not have to adopt those options to start using Hem, and Hem code still gets the §6 guarantees either way.

Hem imports typed TypeScript modules directly. In Vite, the plugin resolves .hem source imports to emitted siblings; other tools consume the emitted modules using their normal resolution rules. Neither direction requires bindings or wrappers.

Part II’s Effect extension is off until you name a transport module in your tsconfig, so nothing in §16 onward applies to a project that has not opted in.

The Effect preview targets the native effect package with effect@4.0.0, configured as hem.effectImportSource: "effect". Generated code uses the package’s public Effect 4 APIs directly. Other versions need their own compatibility checks; Effect 3 is outside the support contract. See Effect setup for dependencies and library imports.

For the setup steps themselves, see how to add Hem to a Vite project; for the options, the configuration reference. Moving existing TypeScript in the other direction is how to migrate TypeScript to Hem.