feat: Add canonical serialization mode to event and variable serialization

[ViktorVovk]

Add canonicalEventSerialization preference for stable, diff-friendly event JSON

Problem

GDevelop's event serialization omits properties that hold default values — disabled, folded, inverted, await are only written to JSON when true; events, variables, subInstructions, loopIndexVariable, etc. are only written when non-empty. This causes two kinds of noise in git diffs:

1. Line insertions / deletions — toggling a boolean flag adds or removes a line, shifting every subsequent line in the block.
2. Unstable key order — JSON object keys are emitted in code-execution order, which differs between event types and changes when events are reorganised.

Both issues make per-event diffs hard to review in version-controlled projects.

Solution

Add a project-level preference canonicalEventSerialization (opt-in, default false). When enabled:

• All conditionally-omitted properties are always written with their default values (false, "", []), so toggling a flag produces a single-line value change, not an insertion/deletion.
• All JSON object keys are written in alphabetical order, giving a stable, predictable layout regardless of event type or serialization order.

The preference is controlled via gdevelop-settings.yaml (already read by the IDE on project open):

# gdevelop-settings.yaml
preferences:
  canonicalEventSerialization: true

[4ian]

toggling a boolean flag adds or removes a line, shifting every subsequent line in the block.

Shouldn't this make things harder to review for a human (or even an AI) because there is less noise?

Unstable key order

Agree it's not great and probably something we can fix!

[ViktorVovk]

Good day @4ian , and thank you for the preliminary review.

I’ll try to answer your question. The idea is that when the canonicalEventSerialization flag is enabled, the saved project JSON already contains all fields with their current values by default.

This way, when a value changes, only the value itself changes, making the diff much clearer — you can simply see that a property changed from true to false or vice versa.

With the default behavior, when a value is false, the field is omitted from the JSON entirely. When it becomes true, the field is added, and if it becomes false again, the field is removed once more. From our perspective, this actually makes the diff harder to read and understand.

[4ian]

Ok, I see the reason behind this. We will see if we can make the implementation a bit less verbose with some dedicated helper (SetBoolAttributeOrEmpty? something that conveys that if "canonical" is not activated, a falsy or default value is not set). Then this will be good to go!

[4ian]

Nitpicking: remove the boolean entirely and instead relying on checking if entry.second.attributeValue != nullptr
(and same for entry.second.childElement != nullptr, out of safety)

[4ian]

We usually don't use prefix with hungarian notation:

Suggested change

	static bool s_canonicalMode;
	static bool canonicalMode;

[4ian]

Added a few comments and I think it will be fine to have this.
I would want ideally all SerializeTo methods to handle silently canonical, but I don't have yet a good idea of how to make this elegantly.