Skip to content

Latest commit

 

History

History
48 lines (39 loc) · 1.86 KB

File metadata and controls

48 lines (39 loc) · 1.86 KB

Running TypeScript

gojs runs TypeScript with no external tooling. The ts package transpiles TypeScript to JavaScript in-process — it embeds a hoisting of Microsoft's typescript-go compiler — and hands the result to the VM.

go run ./examples/typescript

Expected output:

a: distance 5
b: distance 10
c: distance 1.4142135623730951
nearest to origin: c

The same two .ts files also run through the CLI:

go run ./cmd/gojs run ./examples/typescript/main.ts

Key points:

  • ts.Provider(base) wraps any ModuleProvider so that .ts/.tsx modules are transpiled to JavaScript on load. Everything else about module loading — how a specifier resolves, where source comes from — stays with the base provider (here an in-memory map; use NewDirModuleProvider for a directory, or your own provider for a database, archive, or network). The provider is the file-inclusion hook.
  • import "./geometry" resolves through the provider; the .ts extension is retried automatically, so extensionless TypeScript imports work.
  • Transpilation is checker-free (the isolatedModules model): type annotations, interfaces, generics, and class visibility modifiers are erased/lowered, but the program is not type-checked — type errors are ignored. The goal is to run TypeScript, not validate it.
  • For a self-contained script (no imports), ts.RunString(vm, name, src) transpiles and runs in one call.

enum, const enum, and namespace lower and run. Runtime error stack traces are source-mapped back to the original .ts line/column, not the transpiled JavaScript positions. JSX and decorators are not supported — they need a code transform gojs deliberately does not do, so they are rejected with a clear error rather than mis-compiled.