# Babylon.js Editor 5 is a desktop scene builder wrapped in Electron

> Babylon.js Editor 5 is a community managed TypeScript and Electron application for creating Babylon.js 3D scenes visually, with built-in Next.js, Nuxt, Solid, vanilla and Electron templates. It suits artists and web developers who want a GUI scene workflow, and it asks for native build tooling on every platform.

**BabylonJS/Editor** — Community managed visual editor for Babylon.js

- Repository: https://github.com/BabylonJS/Editor
- Website: http://editor.babylonjs.com/
- Stars: 1,121 · Forks: 303
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/babylonjs-editor

## The Editor is a yarn workspace with eleven packages around an Electron shell

Babylon.js Editor 5 is a desktop application for creating and editing 3D scenes with the Babylon.js engine, and it is available on Windows, macOS and Linux. The repository is organised as a yarn workspace list, and the top level package.json names the workspaces explicitly: editor, tools, templates, templates/nextjs, templates/nuxtjs, templates/solidjs, templates/vanillajs, templates/electron, plugins, plugins/quixel, plugins/fab, website, cli and mcp.

That list describes a much larger project than a scene editor. There is a CLI, an MCP server, a website, two plugin packages and five template flavours. The primary language of the repository is TypeScript, and the whole thing is packaged with electron-builder, since the postinstall script runs electron-rebuild for node-pty, then electron-builder install-app-deps, then a local postinstall.mjs.

The electron-rebuild step is the single most consequential line in that file. node-pty is a native module, and native modules have to be compiled against the exact Electron ABI rather than the Node ABI. That one dependency explains most of the installation friction described in the README, and it explains why packaging has to happen on the target operating system.

The Editor is described in the package.json as a web application helping artists to work with Babylon.js, and the README frames the goal in plain terms, focusing on creating rather than coding. The website lives at editor.babylonjs.com and the documentation at editor.babylonjs.com/documentation.

## Templates are the export path, not just starter code

The editor ships built-in templates, and the README calls out a Next.js template specifically, saying it lets you bypass the tedious setup process and go straight to building a project. The workspace list shows the full set: nextjs, nuxtjs, solidjs, vanillajs and electron.

This is the design decision that matters most for adoption. A visual editor that can only produce a scene file for you to import by hand leaves you with the same manual wiring you were trying to avoid. A visual editor with framework templates produces a runnable project, so the scene you assemble in the GUI arrives already wired into a bundler, a dev server and a component structure.

The trade-off is that a template constrains you. The Next.js template gives you a Next.js project, and if your production stack is something else you either adapt or you work in the vanilla template and wire things yourself. The presence of five templates including a plain vanillajs one suggests the project treats the framework choice as a starting point rather than a commitment.

Two plugin packages are also present in the workspace, plugins/quixel and plugins/fab, and the watch-plugins script runs their watchers concurrently with colour coded output and names, quixel and fab. The plugin system is where integrations plug into the editor.

## Native toolchain prerequisites differ sharply across the three platforms

The README treats build prerequisites as a first-class section, which is unusual and useful. On Windows you need tools present in the system like Python and a C++ compiler, and the README offers a shortcut that installs them as administrator in PowerShell:

```bash
# For more information see https://github.com/felixrieseberg/windows-build-tools
npm install --global --production windows-build-tools
```

Two further Windows requirements are spelled out. The Windows SDK is needed, but only the Desktop C++ Apps components. And you need Spectre-mitigated libraries, because otherwise the build fails with the error MSB8040. The fix is described step by step: open the Visual Studio Installer, press Modify, go to the Individual components tab, search Spectre, and install an option such as MSVC v143 - VS 2022 C++ x64/x86 Spectre-mitigated libs, with the exact option depending on your Visual Studio version and your architecture.

On macOS the requirement is XCode, needed to compile the native modules the Editor uses. On Linux with apt it is short:

```bash
sudo apt install -y make python build-essential
```

The Spectre detail is the kind of thing that costs an afternoon if you do not have it in front of you, which is the argument for the README documenting it at all. It is also a reminder that this editor is a native desktop application wearing an Electron jacket, not a browser tool.

## yarn install, yarn build, yarn start, and the watch tasks

The developer loop is short. The repository uses yarn classic, and dependencies are installed with:

```bash
yarn install
```

Building the editor and its associated tools is the build command:

```bash
yarn build
```

Running it from the command line at the root of the repository is:

```bash
yarn start
```

The devtools open automatically, which tells you that the start script launches the application in a debug configuration rather than a production build.

For continuous work, the workspace has a separate watch script per package, and one that watches the Editor together with its dependencies:

```bash
yarn watch-editor-all
```

The package.json shows the granularity. watch-editor runs the babylonjs-editor workspace, watch-editor-css handles styles only, watch-tools, watch-plugins, watch-cli and watch-mcp-server each cover one package, and build-editor, build-tools, build-plugins, build-templates, build-website, build-cli and build-mcp-server are the matching per-package builds. The existence of separate watch and build scripts per workspace package is what makes a monorepo of this size workable.

Visual Studio Code users have a shortcut. The README says you can use a specific task to watch the Editor and other packages, by pressing Ctrl+Shift+B, or Cmd+Shift+B on macOS, and selecting the task watch-all-editor.

## Code formatting and linting run through yarn lint and yarn lint-fix

Before contributing, the README asks that all code is formatted correctly and respects the project's coding rules. Linting is a yarn script:

```bash
yarn lint
```

And the fixable issues are handled by:

```bash
yarn lint-fix
```

The repository backs this with an .eslint/ directory and an eslint.config.mjs file at the root, which is the flat config layout ESLint uses. A prettier.config.mjs file sits next to it, so formatting and linting are separate tools with separate commands rather than one combined pass. There is also a .vscode/ directory and a CLAUDE.md file at the top level, the latter presumably holding instructions for AI assistants working in the repository.

The distinction between lint and lint-fix is worth noting for contributors: lint is a check, lint-fix mutates files. A pull request that arrives with a failing yarn lint has skipped a step the project asked for, and a reviewer will find that out the same way you would have.

## Packaging must happen on the target OS because of the native dependencies

Packaging is the part of the pipeline with the most platform friction, and the reason is stated up front. Due to the native dependencies, builds on macOS must be performed on a macOS machine, and builds on Windows must be performed on a Windows machine with all the requirements installed, which the README lists as XCode, C++ compilers and similar.

The package command takes architecture flags:

```bash
# For the current platform and architecture
yarn package --noSign

# By providing the target architecture
yarn package --noSign --x64

# For both architectures
yarn package --noSign --arm64 --x64
```

The command re-installs the dependencies to make sure they are current, builds the Editor and its tools, and finally packages the Electron application for the target.

Signing on macOS is a separate concern. To sign the application on macOS you need a .env file at the root of the repository with three environment variables set:

```bash
APPLE_ID=
APPLE_APP_SPECIFIC_PASSWORD=
APPLE_TEAM_ID=
```

Once those are in place, you run the package command without the --noSign flag, either yarn package, yarn package --x64, or yarn package --arm64 --x64.

The unsigned path is what a contributor uses, and the signed path is what a maintainer uses to produce the downloadable builds. Those downloads are hosted on a DigitalOcean Spaces bucket, and the README lists v5.5.2 artifacts for Windows x64, macOS on Apple Chip and Intel Chip, and Linux x64 and arm64, the Linux ones being AppImage files.

## Version 5 with weekly releases under Apache-2.0

The project description calls it a community managed visual editor for Babylon.js, and that phrase is the honest summary of its governance. The licence is Apache-2.0, with license.md in the repository root, which is permissive and imposes no copyleft obligations on your own scene tooling. That is a licensing statement rather than legal advice.

The release record is steady. v5.5.2 and v5.5.1 both landed on 2026-09-29, a few minutes apart, and v5.5.0 came on 2026-08-29. The repository is not archived and the last push was on 2026-10-19, so work continues on the master branch.

Two versioning details are easy to misread. The repository title is Babylon.js Editor 5 and the README header says Babylon.js Editor 5, but the root package.json version field reads 5.0.0 while the product name is Babylon.js Editor. The version in the root package.json tracks the monorepo package, while the numbered downloads and releases are the application itself, so the 5.0.0 in the file is not the version of the editor you would download.

The other detail is the release cadence itself. Two releases of the same application on the same day suggests a publish script that runs per merge, which is common for Electron applications where the native rebuild makes each build expensive. For a user, that means the download URLs in the README are version specific and you should re-read them for each release rather than bookmarking a single link.

## Conclusion

Adopt Babylon.js Editor 5 if you build Babylon.js scenes and want to assemble them visually and export through a template rather than hand-writing the scene graph, and if you can meet the native toolchain requirements of your platform. Do not adopt it as a general purpose 3D authoring tool, because it is scoped to the Babylon.js engine and its asset pipeline. Before you start, confirm you have a C++ toolchain and Python on Windows, XCode on macOS, and the build essentials on Linux, because the postinstall step rebuilds node-pty against Electron, and decide whether you need signed macOS builds before you set up the APPLE_ID, APPLE_APP_SPECIFIC_PASSWORD and APPLE_TEAM_ID variables.

## FAQ

### How do I build and run the Babylon.js Editor from source?

The repository uses yarn classic, so run yarn install to get dependencies, yarn build to build the editor and its tools, and yarn start to run it from the root of the repository. The devtools open automatically when it starts.

### What do I need to install before building the Babylon.js Editor on Windows?

You need Python and a C++ compiler, which you can install with npm install --global --production windows-build-tools as administrator in PowerShell, plus the Windows SDK Desktop C++ Apps components and Spectre-mitigated libraries to avoid the MSB8040 build error.

### Why can I not build the Babylon.js Editor package on macOS for a Windows target?

The README explains that because of the native dependencies, builds on macOS must be performed on a macOS machine, and builds on Windows must be performed on a Windows machine with the requirements such as XCode and C++ compilers installed.

### Which project templates does the Babylon.js Editor ship with?

The workspace list includes nextjs, nuxtjs, solidjs, vanillajs and electron templates, and the README highlights the Next.js template as a way to bypass the tedious setup process and start building a project right away.

### How do I sign the Babylon.js Editor application on macOS?

Create a .env file at the root of the repository and set APPLE_ID, APPLE_APP_SPECIFIC_PASSWORD and APPLE_TEAM_ID, then run the package command without the --noSign flag. Use --noSign for unsigned local builds.

## Sources

- [BabylonJS/Editor on GitHub](https://github.com/BabylonJS/Editor)
- [License: Apache-2.0](https://github.com/BabylonJS/Editor/blob/master/LICENSE)
- [Project website](http://editor.babylonjs.com/)
- [README](https://github.com/BabylonJS/Editor/blob/master/README.md)
- [Releases](https://github.com/BabylonJS/Editor/releases)

---

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