Fix saving of Blockly scripts: named timers/schedules under Blockly 13, and functions without statements

[krobipd]

What users see

Since 10.1.0, editing an existing Blockly script that contains a named timeout, interval or schedule does not offer the Save button anymore — changes cannot be saved, and edits made after touching such a block are lost (#2349). Independently, since at least 9.0.11 a script containing a function with a return value whose "statements" checkbox is off cannot be saved either (#1958). Because named timers are among the most common blocks, the first one hits a large share of all existing Blockly scripts.

Why it happens

The editor decides "something changed — show Save" only after it has regenerated the script: workspaceToCode plus Xml.workspaceToDom (the workspace XML travels as a base64 comment behind the generated code). When any single block throws inside that chain, the change handler dies and the Save button never appears — without any visible error.

Two blocks throw:

• The timer and schedule blocks answer getVarModels() with hand-built variable models in the Blockly 11 shape ({ getId, name, type }). Blockly 13 reads variable models through methods — Xml.variablesToDom calls getName()/getType() while saving — so every save of a script containing timeouts_settimeout, timeouts_settimeout_variable, timeouts_setinterval, timeouts_setinterval_variable or schedule_create throws getName is not a function.
• The function generator reads the STACK input unconditionally. With "statements" unchecked the mutation removes that input, and statementToCode throws for a missing one — the same trap the RETURN input is already guarded against one line below.

The fix

• The pseudo variable models now carry getName()/getType()/getId(); the bare name/type properties stay for adapter block files written against the Blockly 11 shape (the compatibility promise of BLOCKLY_TS.md).
• The STACK read is guarded exactly like the RETURN read below it.

Why the snapshots stayed green

The snapshot harness only exercises the code generation, and that path touches getId() only. The harness now additionally saves every corpus block the way the editor does it and reloads the saved XML to the same code — with the two fixes reverted, this new test fails on exactly the five affected block types. A new fixture covers the statement-less function, a state the toolbox (statements on by default) can never show.

Verified

• ✅ npm run test:blockly — 25 passing; with the fixes reverted: 3 failing (the new save test, the new fixture, the snapshot diff)
• ✅ Snapshot diff is empty except for the new fixture's entry — no existing block's generated code changed
• ✅ npm run lint, npm run test:package, npm run build, npm test (declarations + integration, 280 passing) locally on Node 22

Fixes #2349
Fixes #1958

🤖 Generated with Claude Code