Skip to content

Coming from TypeScript or JavaScript

This page is a routing guide for TypeScript and JavaScript developers evaluating Incan for application code, command-line tools, services, and typed domain packages.

Install first

If you already use Node-based tooling, install the npm adapter. It installs command shims plus a host-specific optional platform package for the same prebuilt Incan toolchain payloads used by the release installers, without running an npm lifecycle script:

npm install -g @incan/toolchain
incan --version
incan-lsp --version

The npm path exposes incan and incan-lsp immediately, but it does not run rustup during installation. Make sure Rust and wasm32-wasip1 are available before building projects, or use the direct installer when you want Rust provisioning and explicit control over the toolchain manifest:

curl -fsSL https://github.com/encero-systems/incan/releases/latest/download/install.sh | bash

export PATH="$HOME/.local/bin:$PATH"
incan --version
incan-lsp --version

After installation, create a project and run the normal first-contact loop:

incan new hello --yes
cd hello
incan run
incan test
incan build --release

What you should do next

Mental model translations

  • Types are not erased at the authoring boundary: Incan uses static types for source checking and then compiles through Rust, so the typed API surface is intended to support both humans and tooling before runtime.
  • Errors are values by default: Result, Option, and ? make fallible paths explicit instead of relying on JavaScript-style exceptions for normal control flow.
  • Packages can expose tooling facts: diagnostics, build reports, generated Rust inspection, and codegraph export are public CLI surfaces rather than ad hoc logs.
  • Native output is the current deployment target: Incan is not a JS runtime or a TypeScript transpiler; it is a native toolchain for new application code that should stay readable while compiling through the Rust ecosystem.

Explanation