# GodotJS: TypeScript and JavaScript inside Godot 4.x

> GodotJS is an MIT licensed module that adds a JavaScript and TypeScript scripting language to Godot 4.x, with a choice of V8, QuickJS, JavaScriptCore or the host browser engine, editor debugging, a REPL and hot reloading. The judgement is that the engine abstraction is the project's real content, and that the readme is candid about which of the features are still experimental and which are limited to particular engines.

**godotjs/GodotJS** — Add TypeScript/JavaScript Support for Godot 4.x with v8/QuickJS/JavaScriptCore/Browser

- Repository: https://github.com/godotjs/GodotJS
- Website: https://godotjs.github.io/
- Stars: 767 · Forks: 48
- Language: C
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/godotjs-godotjs

## A script language for Godot with four possible engines underneath

GodotJS adds TypeScript and JavaScript support to Godot 4.x by leveraging the performance of V8 to bring the TypeScript development experience into Godot. The project is a module, written mostly in C, with the repository description naming the engines it can sit on: v8, QuickJS, JavaScriptCore and the browser.

That last option is the one that gives the project its character. The host browser's JavaScript engine can be used as the script engine, which means the same module can run inside a web export of the game, where there is no separate runtime to ship, and a game written against it does not need a different code path for the web build.

The QuickJS and quickjs-ng forks are also in the repository as submodules, which is the pragmatic answer to the question of which JavaScript engine to embed when you want something small and embeddable rather than something large and fast.

Documentation is published at godotjs.github.io, with a getting started page and a separate page listing breaking changes for anyone upgrading from an older version. The project is MIT licensed and the last push to the repository was on 2026-06-13.

## The feature list marks what is finished and what is not

The features are presented as a checklist, and the annotations on it are the useful part.

The Godot ScriptLanguage integration is done, which is the foundation: the module registers itself with the engine as a scripting language, so scripts appear in the editor like any other language and can be attached to nodes.

Debugging is done, and it is engine specific. With V8 you can debug through Chrome or VSCode, and with JavaScriptCore through Safari. That is a meaningful detail, because a JavaScript debugger expects a browser, and the project has to expose the engine to one.

A REPL in the editor is done, and so is hot reloading, which is the feature that makes a TypeScript workflow bearable in a game engine, since the alternative is a rebuild for every change.

The two entries with limits are the ones to look at. Worker threads are supported with limited support and marked experimental. Asynchronously loaded modules are supported with limited support too, and are temporarily only available in the v8.impl and quickjs.impl builds, which means the feature does not exist in the JavaScriptCore or browser configurations at all.

The readme adds one sentence that applies to everything above: the core functionality is implemented and essentially usable but still under testing.

## The engine choice changes what the debugger can attach to

It is worth pulling the engine question apart, because the features do not line up with the engines the way the checklist might suggest.

The debugging story is the clearest case. With V8 the readme points at Chrome and VSCode, and with JavaScriptCore it points at Safari. Both are browsers, and that is the point: the module exposes the engine to a browser based debugger rather than implementing its own protocol. The practical consequence is that the engine you choose determines the debugger you get, and a team that debugs in Chrome should stay on V8, while a team on Apple hardware with JavaScriptCore can use Safari.

The asynchronous module loading limitation is the second case, and it cuts the other way. Dynamically imported modules are limited to the v8.impl and quickjs.impl implementations, so a project that relies on dynamic import is effectively a V8 or QuickJS project, and it will not run the same way under JavaScriptCore or the browser engine.

Worker threads are marked experimental with limited support across the board, so a project that needs them is building on the part of the surface that is most likely to change.

The three main engines therefore differ in more than speed and binary size, and picking one is a commitment that reaches into the debugging workflow and the module system.

## The example project is TypeScript, compiled before you open it

The readme points at a separate example repository, GodotJSExample, for how to use the module in a project, and the examples are written in TypeScript.

There is a step that catches people out. Before opening the example project you are told to run the package install and the TypeScript compiler:

```bash
npm install
npx tsc
```

That is the workflow in miniature. A GodotJS project is a TypeScript project first, compiled to JavaScript, and the Godot side loads the output. The engine is not a TypeScript runtime, and the module does not pretend otherwise, so the compile step is part of opening the project rather than part of an export.

Two of the examples are shown as animated captures, a Snake game and a Jummpy Bird game, which is a reasonable way to demonstrate both that the module works and that the projects are small enough to read.

For a reader deciding whether to try this, the example repository is the faster path than the documentation, because it shows the whole loop, the TypeScript sources, the compiled output, the project file and the Godot side, in a repository you can open and run.

## A C++ module with a pnpm workspace sitting on top of it

The repository is two projects in one, and the directory listing shows the seam.

The native side is a Godot module: config.py and SCsub are the SCons build files the engine uses, register_types.cpp and register_types.h are the entry points where the scripting language is registered, and the jsb prefixed headers, jsb.h, jsb.config.h, jsb.natvis, jsb_project_preset.h and jsb_version.h, are the module's own headers. The jsb.natvis file is a Visual Studio debugger visualisation file, which tells you the native debugging story is aimed at Windows developers.

Inside that sit the directories that hold the implementations and the glue: impl for the per-engine implementations, bridge for the layer between the engine and Godot, compat for compatibility shims, internal for shared internals, and weaver and weaver-editor for the build tooling. The quickjs and quickjs-ng directories are the engine sources as submodules, and tests and scripts hold the test harness and the release scripts.

On top of that sits a pnpm workspace. The package manifest is named @godot-js/editor, marked private, and pins pnpm at 10.11.0 with an integrity hash. Its scripts are the release pipeline: build runs the recursive build, test runs a runtime matrix through scripts/test/run-runtime-matrix.mts, and the release scripts are should-publish, publish, test-project and version, where version runs changeset version followed by the project's own release script. Changesets handles the version bumps and the changelog.

The runtime matrix test is the detail to notice. A module that can run on four different engines needs a test that runs on all of them, and the script name says that is what it does.

## Release numbers carry the Godot version they were built for

The release tags explain how this project is versioned against the engine it extends.

The three listed releases are v1.1.0-pre-godot46rc3 on 2026-03-26, v1.1.0.alpha3-4.6.1 on 2026-04-20 and v1.1.0.beta1-4.6.1 on 2026-04-21. Each name carries the Godot version it was built against, 4.6.1 in the two April tags and a Godot 4.6 release candidate in the March one, and the alpha and beta labels are the module's own maturity markers rather than the engine's.

That is a sensible scheme for a module that is versioned against a moving host, because it answers the question a user actually has, which is which Godot release this build is for, without making anyone read a compatibility table.

The beta naming also lines up with the note in the readme about the core functionality being essentially usable but still under testing. A beta tag on a module that is under test is a reasonable signal.

For anyone upgrading, the readme points at a breaking changes page, which is the document to read first, because a module that tracks the host engine closely is also a module whose interface moves when the engine moves. The repository also carries a CHANGELOG, a CONTRIBUTING guide and a .node-version file, which pins the Node version the tooling expects.

## Conclusion

GodotJS fits a team that wants to write Godot game logic in TypeScript and reuse the same editor, debugger and tooling they already use for web work, because the module registers a real script language, ships a REPL in the editor and can debug through Chrome or VSCode with V8 and through Safari with JavaScriptCore. It is the wrong choice if you need stable production tooling today, because the readme states that the core functionality is implemented and essentially usable but still under testing, and it is the wrong choice if you need every feature on every engine, since worker threads are experimental and asynchronously loaded modules are limited to the v8.impl and quickjs.impl builds. Before you commit, read the breaking changes page for your version, decide which engine you will ship, and check whether the features you need are on the checklist or in the experimental column.

## FAQ

### What is GodotJS?

It is a module that adds TypeScript and JavaScript support to Godot 4.x by registering a script language with the engine, so scripts can be written in TypeScript, compiled and attached to nodes like any other language in the project.

### Which JavaScript engines does GodotJS support?

V8, QuickJS, quickjs-ng, JavaScriptCore and the host browser engine. The choice matters beyond speed, because debugging works through Chrome or VSCode with V8 and through Safari with JavaScriptCore, and asynchronously loaded modules are limited to the v8.impl and quickjs.impl builds.

### Which features of GodotJS are still experimental?

Worker threads are supported with limited support and are marked experimental, and asynchronously loaded modules are also limited, temporarily only in the v8.impl and quickjs.impl builds. The readme adds that the core functionality is implemented and essentially usable but still under testing.

### How do I run a GodotJS example project?

Run npm install and npx tsc in the example project before opening it in Godot, because the TypeScript has to be compiled to JavaScript first. The example repository GodotJSExample contains the TypeScript sources, including a Snake game and a Jummpy Bird game.

## Sources

- [godotjs/GodotJS on GitHub](https://github.com/godotjs/GodotJS)
- [License: MIT](https://github.com/godotjs/GodotJS/blob/main/LICENSE)
- [Project website](https://godotjs.github.io/)
- [README](https://github.com/godotjs/GodotJS/blob/main/README.md)
- [Releases](https://github.com/godotjs/GodotJS/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/godotjs-godotjs