John Smith
48ed4e38d0
Two problems made this fork expensive to maintain: scanner noise nobody could act on, and divergence from upstream that nothing tracked. Code scanning reported 3,518 open alerts. 3,449 were fallow findings and 2,399 of those sat in vendored bundles `.fallow.toml` never listed (jolt-physics.wasm.js 436, box2djs/box2d.js 328, the Firebase SDK 655, Recast, PeerJS, draco). Listing them plus raising the CRAP thresholds from the defaults to evidence-based values takes fallow from 3,449 findings to 155, all in maintained code. The remaining 69 were CodeQL: 8 third-party actions are now pinned to full commit SHAs with `# vN` comments (so Dependabot keeps updating them) and all 10 workflows declare an explicit least-privilege `permissions:` block. SonarCloud's 2,845 open issues are mostly not this fork's code — 2,526 sit in files byte-identical to upstream. The real defect was configuration: ~200 lines of `sonar.issue.ignore.multicriteria.e1..e88` in .sonarcloud.properties, plus scripts/sonarcloud-apply-suppressions.sh, were inert. That key is a Project Settings UI setting and cannot be read from that file under automatic analysis, so two phases of remediation work chased config the server never saw. Both are deleted; the exclusions that do work are kept and extended. `sonar.test.inclusions` no longer declares production source directories as test inclusions. Divergence is now bounded and checked. `fork-divergence.json` is a checked-in allowlist of the 111 modified, 51 fork-only and 7 upstream-missing paths, and `scripts/check-fork-divergence.js` fails CI on divergence that is not listed or on stale entries. It reads upstream through the GitHub trees API because 4ian/GDevelop is ~1.7GB and this runs on every PR. Restoring Extensions/Physics3DBehavior/tests/ Physics3DRuntimeBehavior.spec.js — deleted by an earlier SonarCloud pass to silence one rule — removes one entry each. Repairs found along the way: every `// nosonar` marker sat on the line before the statement SonarCloud flags, where the directive does nothing; each is now on the exact reported line. Four garbled comment fragments left in multiplayertools.ts by the same pass are gone. A two-line re-export shim with no importers (AiGeneration/CustomAIClient.js) is deleted. `scripts/sonarcloud-drift.js` now writes its outputs to $GITHUB_OUTPUT and seeds its own baseline, so the weekly drift job's ceiling can actually fire; it previously ran behind `continue-on-error` against a threshold that predated the exclusions and was unreachable. Root documentation collapses to MAINTENANCE.md. The three SonarCloud phase plans and the Dependabot plan described steps that were proven impossible and are deleted; AI_GAME_STUDIO_ASSESSMENT.md is a design record and stays. Verified: newIDE/app 176/176 suites and 1,922 tests pass; GDevelop.js 33/33 suites and 1,177 tests pass; GDJS Karma 1,287 pass with the same 9 pre-existing failures (Firebase network tests) reproduced on a pristine tree. check-format lists 37 files against the documented 41-file baseline, so no new violations. Lockfile, drift and divergence guards all exit 0.
GDevelop.js
These are the bindings of GDevelop core classes to WebAssembly+JavaScript. This allows GDevelop Core libraries to run in a browser or on Node.js.
How to build
👋 Usually, if you're working on the GDevelop editor or extensions in JavaScript, you don't need to rebuild GDevelop.js. If you want to make changes in C++ extensions or classes, read this section.
-
Prerequisite tools installed:
- CMake 3.17+ (3.5+ should work on Linux/macOS). On macOS, you can install it via Homebrew (recommended for Apple M1 Architectures).
- Node.js. (We recommend using nvm to be able to switch between Node versions easily).
- Python (via pyenv for versions management).
-
Install Emscripten version
3.1.21, as explained below or on the Emscripten installation instructions:git clone https://github.com/emscripten-core/emsdk/ cd emsdk git pull ./emsdk install 3.1.21 ./emsdk activate 3.1.21 # On Windows, also install an additional Python package: pip install setuptools -
Whenever you try to build GDevelop.js in the future, you will have to load the emsdk environement into your terminal window again by running:
Linux/macOS Windows (Powershell) Windows (cmd.exe) source ./emsdk_env.sh./emsdk_env.ps1./emsdk_env.bat -
With the emscripten environement loaded into your terminal, launch the build from GDevelop.js folder:
cd GDevelop.js npm install # Only the first time. npm run build # After any C++ changes.⏱ The linking (last step) of the build can be made a few seconds faster, useful for development:
npm run build -- --variant=dev. -
You can then launch GDevelop 5 that will use your build of GDevelop.js:
cd .. cd newIDE/app npm install npm start
More information in GDevelop 5 README.
Tests
npm test
Debugging
You can build the library with various level of debugging and memory checks.
npm run build -- --variant=debug # Build with debugging information (useful for stacktraces)
npm run build -- --variant=debug-assertions # Build with assertions and "SAFE_HEAP=1", useful to find memory bugs.
npm run build -- --variant=debug-sanitizers # Build with memory sanitizers. Will be very slow.
It's then recommended to run the tests (npm test) to check if there are any obvious memory bugs found.
About the internal steps of compilation
The npm build task:
- Creates
Binaries/embuilddirectory, - Launches CMake inside to compile GDevelop with emconfigure to use Emscripten toolchain,
- Updates the glue.cpp and glue.js from Bindings.idl using Emscripten WebIDL Binder,
- Launches the compilation with
make(orninjaon Windows with CMake 3.17+) (you can also compile using MinGW-32 usingnpm run build-with-MinGW).
See the CMakeLists.txt for the arguments passed to the Emscripten linker. For instance, if you want to see the function names in stacks or for profiling, the compilation flags can be changed.
Documentation
- The file Bindings.idl describes all the classes available in GDevelop.js.
- Refer to GDevelop documentation for detailed documentation of the original C++ classes.