GDevelop addresses the gap between visual, no-code game editors and engines that require programming. Most engines force a choice: either a visual tool with limited depth, or a code-first engine with a steep learning curve. GDevelop's event-based system and modular behaviors aim to let non-programmers build 2D, 3D, and multiplayer games while keeping the engine itself open and extensible.
What This Does
This repo is a fork of the upstream 4ian/GDevelop (25,970 stars) and is a collection of six self-contained projects, not a single codebase. The newIDE/ folder (3,596 files) is the React-based editor where games are designed. GDJS/ (1,027 files) is the JavaScript game engine runtime that executes the games. Core/ (551 files) holds the C++ game logic core, and GDevelop.js/ (313 files) binds that C++ core to JavaScript via Emscripten.
The build is CMake-driven (CMakeLists.txt at root and in Core/, Extensions/, Extensions/3D/), with yarn as the package manager and Travis CI plus GitHub Actions for CI/CD. The runtime ships for multiple targets: web (GDJS/Runtime/index.html), Electron (GDJS/Runtime/Electron/main.js), Cordova, and Facebook Instant Games.
How It Is Wired
The wiring has not been mapped for this repository yet — no internal call graph or traced execution paths were produced. What the structure shows: the editor (newIDE/) composes game logic through the C++ core (Core/) exposed via GDevelop.js/ bindings, and the runtime (GDJS/) executes that logic in the browser or on device. The 1,044 test files are split across Core/tests/main.cpp, GDJS/tests, and the IDE's test suites, but no test command appears in the four GitHub Actions workflows read — a finding covered below.
How To Use It
The README directs contributors to newIDE/README.md for editor/engine development. Build steps are not documented in the root README excerpt; the CMake files imply a C++ build for Core/, and the package.json files in GDJS/ and GDJS/Runtime/Electron/ imply yarn install for the runtime. Exact commands are not present in the repo's root documentation, so verify against newIDE/README.md before running.
Real-World Use
A developer extending GDevelop writes a new behavior as an extension under Extensions/ (532 files), following the extension creation guide linked in the README. The extension is compiled through the CMake targets (Extensions/CMakeLists.txt) and exposed to the editor, where a game designer wires it to sprites via the event system without touching code — the core value proposition of the platform.
Code Health & Issues
The following comes from static analysis of this repo, not opinion:
High — Committed .env file: newIDE/app/.env is tracked and the app loads it. Remove from git, rotate every credential, commit a .env.example.
High — Third-party GitHub Actions pinned to tags, not SHAs: .github/workflows uses aws-actions/configure-aws-credentials@v2, chromaui/action@v1, peter-evans/*@v3/@v2. Tag moves can swap the code running with your token.
High — No lockfile beside SharedLibs/ThreeAddons/package.json; untested transitive versions can ship.
High — CI declares no test command across the 4 workflows despite 998 test files; the green check asserts nothing.
Medium — No permissions: declaration on workflows that reference secrets; GITHUB_TOKEN inherits repo default.
Medium — No Dependabot/Renovate config despite 11 manifests.
Medium — No dependency vulnerability scan in CI.
Medium — No pre-commit secret gate; the .env leak will recur.
Medium — persist-credentials not set to false on checkout in .github/workflows/build-storybook.yml.
Low — No timeout-minutes on workflow jobs.
The Bottom Line
This is the real GDevelop engine — a substantial, mature codebase with a serious editor, a C++ core, and a multi-target runtime. The engineering is solid; the hygiene gaps are the concern: a live .env, unpinned CI actions, and CI that doesn't run its own tests. Use it to build or extend a no-code game engine, but fix the secrets and CI issues before treating it as production infrastructure.
What the analyser found
Deployment readiness
5/7
✗Container image
✓CI pipeline
✓Lockfile committed
✓Test suite
✓README
✓License
✗No committed secrets
Composition
6,125 files
JavaScript2614
C++350
TypeScript330
C/C++ Header325
JSON97
CSS55
ReactExpressPyTorch
Dependencies
8 of 21 declared dependencies are a major version behind. Resolved 21 of 21 against the registry.
Package
Declared
Latest
Behind
gdjs_extension_npm_dependency
0
99.0.0
99 major
@types/node
^14.11.1
26.2.0
12 major
@types/sinon
^10.0.13
22.0.0
12 major
electron
32.3.3
43.4.0
11 major
@types/mocha
^5.2.7
10.0.10
5 major
patch-package
^6.4.7
8.0.1
2 major
typescript
5.4.5
7.0.2
2 major
pixi.js
7.4.2
8.19.0
1 major
Findings
LowSecret-shaped paths present; the code-health audit confirms or clears them newIDE/app/.env
Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.
high5
medium5
low1
Pin third-party GitHub Actions to a commit SHAhigh5 occurrences
A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.
Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.
Upgrade the pinned dependency carrying a published advisoryhigh32 occurrences
electron@32.3.3 CVE-2026-34774 (high) +31 more
The pinned version is the one that installs, so a published advisory against it describes this deployment rather than a hypothetical one, and the advisory is also a public description of how to exploit it.
Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.
Commit a lockfile beside the manifesthigh
SharedLibs/ThreeAddons/package.json
manifest with no lockfile in scope
An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.
Fix: Run the package manager once and commit the generated lockfile.
Remove the committed .env and rotate what it holdshigh
newIDE/app/.env
newIDE/app/.env
A tracked .env is the most common route for a working key to reach a public clone, and it is the file the app actually loads, so the value is usually live.
Fix: git rm --cached the file, add it to .gitignore, rotate every credential it names, commit a .env.example with empty values.
Make CI invoke the test suite it hashigh998 occurrences
.github/workflows
998 test files, no test command in the 4 workflows read
A green check that never executed an assertion is worse than no check, because reviewers trust it.
Fix: Add a test step to the existing workflow rather than a new workflow.
Declare least-privilege permissions for GITHUB_TOKENmedium4 occurrences
.github/workflows/build-storybook.yml
4 workflow(s) declare no permissions, 4 of them reference secrets
With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.
Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.
Enable Dependabot or Renovatemedium
11 manifest(s), no update bot configured
Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.
Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.
Gate pull requests on a dependency vulnerability scanmedium
.github/workflows
no dependency scan in CI
This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.
Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.
Add a pre-commit secret gatemedium
a secret-shaped file is tracked and no repo-level gate is visible
Without a gate the same class of leak recurs on the next commit, so a leak finding is the symptom and this is the cause.
Fix: Add a pre-commit hook scanning staged content, and enable push protection.
Set persist-credentials: false on checkoutmedium
.github/workflows/build-storybook.yml
checkout keeps the token, then dependencies are installed
The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.
Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.
Set timeout-minutes on the workflow jobslow4 occurrences
.github/workflows/build-storybook.yml
4 workflow(s) declare no job timeout
A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.
Fix: Add timeout-minutes with a realistic bound to each job.
Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.