cables: the JavaScript core behind a visual programming editor

Two products, one repository, one vendor

cables is described as a tool for creating beautiful interactive content, and it reaches users through two front doors: cables.gl, the hosted platform, and cables standalone, the local edition. The project is mainly developed by undev, with contributions from the cables community through a Discord channel, and support from a list of other parties and projects collected on a support page.

That structure tells you what the repository is. It is the engine and the editor core of a product with a commercial owner, not a standalone open source project with a community governance model. The development instructions are unusually short for a codebase of this size, and they point elsewhere: the preferred way of developing cables locally is the cables_dev repository, which contains scripts that set everything up, and the official documentation has a section called Developing Cables.

The default branch is develop, not main or master, and there are no GitHub releases. Development therefore happens on a branch that also carries the bleeding edge work, and there is no tag to pin if you want to build a known good version.

What the top level directory actually contains

The listing is compact enough to read in full: .gitattributes, .github, .gitignore, .npmrc, .nvmrc, README.md, gulpfile.js, gulpfile_tests.js, op.schema.json, package-lock.json, package.json, src/, webpack.config.corelibs.js and webpack.config.js. A reader looking for a library will not find one at the root. The bulk of the code sits under src/, and the package entry point is declared as src/core/index.js.

Two configuration files carry weight. op.schema.json is a JSON schema, and gulp-json-schema is a development dependency, which suggests the schema is validated as part of the build rather than being documentation only. The two webpack configs split the build in two: webpack.config.js for the main bundle and webpack.config.corelibs.js for the core libraries, which is a common way to keep the library half of an editor out of the application bundle.

The package manifest is marked private, so nothing here is published to a registry under the cables name, and the version field is a flat 1.0.0 rather than a sequence of published releases. The manifest also declares the package as an ES module with type set to module, which matters for anyone dropping a piece of this code into a CommonJS project.

gulp drives the build, webpack does the bundling

The build is a two layer arrangement. gulp is the task runner that a developer actually invokes, and webpack is the bundler underneath it. The npm scripts in the manifest give the full set of entry points:

    "scripts": {
        "postinstall": "cd src/corelibs/ && npm install --no-save --ignore-scripts cables",
        "build": "gulp build",
        "build:live": "gulp build",
        "watch": "gulp watch",
        "analyze": "gulp analyze",
        "test": "gulp --gulpfile gulpfile_tests.js"
    },

Note that build and build:live are the same command, which tells you the live variant was planned as a separate mode and has not diverged in the manifest. watch is the continuous rebuild, analyze is the bundle size inspection that webpack-bundle-analyzer enables, and test points at a different gulpfile, gulpfile_tests.js, so the test run is separated from the main task graph rather than being a task inside it.

The dev dependency list explains the rest of the toolchain. webpack 5.91.0 with webpack-cli 6.0.1 does the bundling, terser-webpack-plugin 5.3.10 handles minification, raw-loader 4.0.2 pulls in non JavaScript assets, and two more unusual entries stand out. git-last-commit pulls the current commit into the build, and @k88/module-scope-plugin suggests the project enforces some kind of module scoping rule that a plain webpack setup would not have caught. The @webgpu/types dependency at 0.1.53 points at WebGPU type definitions being part of the source.

Node is pinned to 24.18.1 and the package expects a sibling checkout

Two details in the manifest will stop a naive clone. The first is the engine pin:

    "engines": {
        "node": "24.18.1"
    },

An exact version rather than a range, and the .nvmrc file at the top level exists to make that version selectable without guesswork. A build that fails on a newer Node is therefore not a mystery, it is a version mismatch with a documented answer.

The second is the dependency on a directory that is not in this repository:

    "dependencies": {
        "@webgpu/types": "0.1.53",
        "cables-shared-client": "file:../shared/client/"
    },

cables-shared-client resolves through a file path, ../shared/client/, which means the install expects a sibling directory named shared with a client folder inside it. A fresh clone of this repository on its own does not satisfy that path, and npm will not fetch it from a registry because there is no registry entry to fetch. This is the single most likely reason a first build attempt fails.

The postinstall script answers the same question from the other side. It changes into src/corelibs/ and installs the cables package there with --no-save and --ignore-scripts, so the core library is placed where the build expects it and is deliberately kept out of the lock file. The result is a build that depends on a specific local layout, which is exactly what the cables_dev setup scripts exist to create.

Contribution happens through issues, milestones and a nightly stream

The issue workflow is described precisely enough to be worth following as a process. You create an issue and pick either Bug report or Feature Request from the templates. The issue is assigned a new label, the maintainers check the issues regularly, add them to a milestone and remove the new label, and the issue is closed once the change has landed in any release, including the dev and nightly streams. Stable releases then carry a changelog listing all the closed issues.

Two things fall out of that description. First, closing an issue is tied to a release rather than to a merge, so the milestone is where a contributor can see when a change is expected to ship. Second, a nightly stream means that a build you test can move underneath you, and the changelog of closed issues in a stable release is the better reference point for anyone who needs to know what a specific version contains.

For code contributions, the contribution route runs through the cables_dev repository rather than through this one. The README calls that the preferred way of developing cables locally, states that it contains scripts that set up everything needed to get started, and points to the Developing Cables section of the official documentation for the full procedure.

The licence is the murkiest part of the repository

The manifest declares a licence, and it is not a subtle one:

    "license": "MIT",

But the repository itself has no detected licence, and there is no LICENSE file among the top level entries. The listing contains.gitattributes,.github,.gitignore,.npmrc,.nvmrc, the README, the build files, the schema, the manifests, src/ and the two webpack configs, and nothing that reads as a licence text. That gap matters for a codebase owned by a company, because a licence string inside a package manifest is a claim about the package, while the absence of a licence file leaves an outside reader without the actual terms and conditions to comply with.

The package is also marked private, so it is not on a registry for someone to fetch under those terms. Whatever the arrangement is, it is between cables and the people who wrote it, and the public artefact does not spell it out. Anyone planning to reuse code from src/ in a product of their own, or to contribute, should ask for the terms in writing rather than relying on the MIT string, which may simply be a placeholder in a private manifest.

On maintenance, the last push was on 2026-10-22 and the repository is not archived, so work is continuing on the develop branch. The absence of GitHub releases remains the bigger issue for consumers: there is no version history to pin, and the 1.0.0 in the manifest is not a released artefact.

Hosted platform against standalone editor, and what the README leaves out

The natural alternative to building this repository is to use the products that come out of it. cables.gl is the hosted platform, and cables standalone is the version that runs without a hosted service. Both are described in one line of the README, and both are linked, but the project documentation, not the README, is where the difference in operation lives. The README does not describe what the standalone edition requires, whether it can be deployed on your own infrastructure, or how the two differ in features, and a reader is left to work that out from the documentation and the support page.

The same pattern applies to the build system. Instead of adopting the gulp and webpack arrangement described here, a team could assemble its own pipeline around webpack 5 and the schema, and the manifest makes that conceivable since the pieces are listed separately. What it does not make conceivable is a supported result: the module scope plugin, the schema validation step, the core library install and the bundle analysis are wired together by the gulp tasks, and reimplementing them is a maintenance commitment rather than a shortcut.

For an evaluation, the practical split is this. If the goal is to publish interactive content, the hosted platform is the route and this repository is irrelevant to you. If the goal is to work on the editor runtime itself, then the choice is between following the cables_dev setup, which the README calls the preferred path, and assembling a local environment by hand against a manifest that expects Node 24.18.1, a sibling shared client directory and a core library pulled in by a postinstall step.

Editorial conclusion

cables suits an engineer who wants to work on the runtime behind a node based visual editor, or who wants to extend the platform and is prepared to follow the gulp and webpack layout rather than invent their own. It is the wrong starting point for a team that just wants to publish interactive content, because the repository is a private package with no tagged releases and no licence file, so there is nothing to install from npm and nothing to redistribute yet. Check three things before you start: the node version in .nvmrc, whether you have the sibling shared client checkout that the file: dependency points at, and what the actual licence terms are, since the MIT string in package.json is the only licence statement the repository makes.

Frequently asked questions

Official sources

1. cables-gl/cables on GitHub
2. Issues
3. Project website
4. README