Bump the toolchain group with 3 updates

[dependabot]

Bumps the toolchain group with 3 updates: @abaplint/cli, @abap2ui5/linter and @abap2ui5/render-runtime.

Updates @abaplint/cli from 2.120.33 to 2.120.39

Commits

• 6bb7b53 chore(release): v2.120.39 (#4258)
• 055a1c5 bugfix syntax (#4257)
• b59f53b chore(release): v2.120.38 (#4256)
• 44a4618 bugfix chain_mainly_declarations + implicit_start_of_selection (#4255)
• e4d75e7 chore(release): v2.120.37 (#4253)
• f987df4 bugfix PERFORM (#4252)
• 556cf72 chore(release): v2.120.36 (#4250)
• 7028282 bugfix (#4249)
• a5a2647 chore(release): v2.120.35 (#4248)
• 2438423 bugfix ALIAS (#4247)
• Additional commits viewable in compare view

Updates @abap2ui5/linter from 0.3.0 to 0.5.1

Release notes

Sourced from @​abap2ui5/linter's releases.

v0.5.1

• backToPage joins the id-argument mirror. abap2UI5 gave it the pageId kind (#2670) after measuring that an unprefixed page id is a silent no-op, so check-upstream re-derived the list and CONTROL_METHOD_ID_ARG was one entry short — turning a consumer's check:mirrors red on correct new code, which is the failure mode that gate exists to make loud.

  Worth keeping apart from to, and the comment now says so: backToPage does normalise a Control (NavContainer.js:1065, the same guard to has), so the kind is not there to rescue a Control. It is there because the id is matched against _pageStack, whose every entry was pushed as page.getId(), so _findClosestPreviousPageInfo compares with === (NavContainer.js:1203) and an unprefixed literal matches nothing, logs, and returns without navigating.

  Patch rather than minor: measured on samples-controls before shipping — 0 findings added, 60 advisory unchanged, so no consumer's verdict moves.

v0.5.0

• The pageId argument kind, so the mirror stops calling to stale. abap2UI5 moved CONTROL_METHODS.to from the controlId kind to a new pageId kind, because sap.f.FlexibleColumnLayout.to and sap.m.SplitContainer.to probe their columns with aPages[i].getId() == pageId — a comparison a Control can never win, so every probe missed and the trailing else navigated the last column.

  check-upstream derived the id-argument list from the controlId / anchor / controlIdOrNull kinds only, so the new kind read as to is gone upstream and failed the consumer's check:mirrors. But pageId still resolves a control id — resolveControl( ) first, .getId( ) after — so what an app writes on the ABAP side is unchanged and still has to exist in the view. The kind records a fact about the container, not about the argument this list checks, so to belongs in CONTROL_METHOD_ID_ARG exactly as before and the derivation now admits pageId. Without this, abap2UI5 cannot merge the fix that introduced the kind: its mirror gate is red until a linter that knows about it ships.

• date-type-without-source reads the QUOTED key spelling. A binding-info may be written { 'type': 'sap.ui.model.type.Date' } as legitimately as with bare keys, and samples-controls apps 017/018 write all eight of their date bindings that way. The matcher required a bare type:, so it stopped at the first test and never judged them — blind, not wrong.

  The fix has to move both halves together, which is the whole point: the source test required a bare source: too, so teaching the rule the quoted 'type' alone would have turned those eight correct bindings into findings, because their 'source' is quoted as well. Value quotes may now be single or double for the same reason. Corpus after the change: 0 findings, total unchanged at 747 — the eight are now read and correctly cleared by their own source pattern, rather than skipped because the rule could not see them.

... (truncated)

Changelog

Sourced from @​abap2ui5/linter's changelog.

0.5.1 - 2026-08-27

• backToPage joins the id-argument mirror. abap2UI5 gave it the pageId kind (#2670) after measuring that an unprefixed page id is a silent no-op, so check-upstream re-derived the list and CONTROL_METHOD_ID_ARG was one entry short — turning a consumer's check:mirrors red on correct new code, which is the failure mode that gate exists to make loud.

  Worth keeping apart from to, and the comment now says so: backToPage does normalise a Control (NavContainer.js:1065, the same guard to has), so the kind is not there to rescue a Control. It is there because the id is matched against _pageStack, whose every entry was pushed as page.getId(), so _findClosestPreviousPageInfo compares with === (NavContainer.js:1203) and an unprefixed literal matches nothing, logs, and returns without navigating.

  Patch rather than minor: measured on samples-controls before shipping — 0 findings added, 60 advisory unchanged, so no consumer's verdict moves.

0.5.0 - 2026-08-27

• The pageId argument kind, so the mirror stops calling to stale. abap2UI5 moved CONTROL_METHODS.to from the controlId kind to a new pageId kind, because sap.f.FlexibleColumnLayout.to and sap.m.SplitContainer.to probe their columns with aPages[i].getId() == pageId — a comparison a Control can never win, so every probe missed and the trailing else navigated the last column.

  check-upstream derived the id-argument list from the controlId / anchor / controlIdOrNull kinds only, so the new kind read as to is gone upstream and failed the consumer's check:mirrors. But pageId still resolves a control id — resolveControl( ) first, .getId( ) after — so what an app writes on the ABAP side is unchanged and still has to exist in the view. The kind records a fact about the container, not about the argument this list checks, so to belongs in CONTROL_METHOD_ID_ARG exactly as before and the derivation now admits pageId. Without this, abap2UI5 cannot merge the fix that introduced the kind: its mirror gate is red until a linter that knows about it ships.

• date-type-without-source reads the QUOTED key spelling. A binding-info may be written { 'type': 'sap.ui.model.type.Date' } as legitimately as with bare keys, and samples-controls apps 017/018 write all eight of their date bindings that way. The matcher required a bare type:, so it stopped at the first test and never judged them — blind, not wrong.

  The fix has to move both halves together, which is the whole point: the source test required a bare source: too, so teaching the rule the quoted 'type' alone would have turned those eight correct bindings into findings, because their 'source' is quoted as well. Value quotes may now be single or double for the same reason. Corpus after the change: 0 findings, total

... (truncated)

Commits

• 8ae804f release v0.5.1 — backToPage joins the id-argument mirror (#65)
• 5f03b6f release v0.5.0 — two new rules, a widened one, and a 16-entry enum-snapshot r...
• bbd9e19 release v0.4.1 - relative-aggregation-without-context on an element-bound slo...
• 813466e release v0.4.0 (#62)
• b2eb4ae Six rules from the generated re-read, and two version checks that were lookin...
• 8a716fe Read @​ui5-experimental-since, a relative-asset-url rule, and two mirror corre...
• a443955 Render the "Used by" list ourselves — GitHub's panel needs 100 dependents (#59)
• See full diff in compare view

Updates @abap2ui5/render-runtime from 0.3.0 to 0.5.1

Release notes

Sourced from @​abap2ui5/render-runtime's releases.

v0.5.1

• backToPage joins the id-argument mirror. abap2UI5 gave it the pageId kind (#2670) after measuring that an unprefixed page id is a silent no-op, so check-upstream re-derived the list and CONTROL_METHOD_ID_ARG was one entry short — turning a consumer's check:mirrors red on correct new code, which is the failure mode that gate exists to make loud.

  Worth keeping apart from to, and the comment now says so: backToPage does normalise a Control (NavContainer.js:1065, the same guard to has), so the kind is not there to rescue a Control. It is there because the id is matched against _pageStack, whose every entry was pushed as page.getId(), so _findClosestPreviousPageInfo compares with === (NavContainer.js:1203) and an unprefixed literal matches nothing, logs, and returns without navigating.

  Patch rather than minor: measured on samples-controls before shipping — 0 findings added, 60 advisory unchanged, so no consumer's verdict moves.

v0.5.0

• The pageId argument kind, so the mirror stops calling to stale. abap2UI5 moved CONTROL_METHODS.to from the controlId kind to a new pageId kind, because sap.f.FlexibleColumnLayout.to and sap.m.SplitContainer.to probe their columns with aPages[i].getId() == pageId — a comparison a Control can never win, so every probe missed and the trailing else navigated the last column.

  check-upstream derived the id-argument list from the controlId / anchor / controlIdOrNull kinds only, so the new kind read as to is gone upstream and failed the consumer's check:mirrors. But pageId still resolves a control id — resolveControl( ) first, .getId( ) after — so what an app writes on the ABAP side is unchanged and still has to exist in the view. The kind records a fact about the container, not about the argument this list checks, so to belongs in CONTROL_METHOD_ID_ARG exactly as before and the derivation now admits pageId. Without this, abap2UI5 cannot merge the fix that introduced the kind: its mirror gate is red until a linter that knows about it ships.

• date-type-without-source reads the QUOTED key spelling. A binding-info may be written { 'type': 'sap.ui.model.type.Date' } as legitimately as with bare keys, and samples-controls apps 017/018 write all eight of their date bindings that way. The matcher required a bare type:, so it stopped at the first test and never judged them — blind, not wrong.

  The fix has to move both halves together, which is the whole point: the source test required a bare source: too, so teaching the rule the quoted 'type' alone would have turned those eight correct bindings into findings, because their 'source' is quoted as well. Value quotes may now be single or double for the same reason. Corpus after the change: 0 findings, total unchanged at 747 — the eight are now read and correctly cleared by their own source pattern, rather than skipped because the rule could not see them.

... (truncated)

Changelog

Sourced from @​abap2ui5/render-runtime's changelog.

0.5.1 - 2026-08-27

• backToPage joins the id-argument mirror. abap2UI5 gave it the pageId kind (#2670) after measuring that an unprefixed page id is a silent no-op, so check-upstream re-derived the list and CONTROL_METHOD_ID_ARG was one entry short — turning a consumer's check:mirrors red on correct new code, which is the failure mode that gate exists to make loud.

  Worth keeping apart from to, and the comment now says so: backToPage does normalise a Control (NavContainer.js:1065, the same guard to has), so the kind is not there to rescue a Control. It is there because the id is matched against _pageStack, whose every entry was pushed as page.getId(), so _findClosestPreviousPageInfo compares with === (NavContainer.js:1203) and an unprefixed literal matches nothing, logs, and returns without navigating.

  Patch rather than minor: measured on samples-controls before shipping — 0 findings added, 60 advisory unchanged, so no consumer's verdict moves.

0.5.0 - 2026-08-27

• The pageId argument kind, so the mirror stops calling to stale. abap2UI5 moved CONTROL_METHODS.to from the controlId kind to a new pageId kind, because sap.f.FlexibleColumnLayout.to and sap.m.SplitContainer.to probe their columns with aPages[i].getId() == pageId — a comparison a Control can never win, so every probe missed and the trailing else navigated the last column.

  check-upstream derived the id-argument list from the controlId / anchor / controlIdOrNull kinds only, so the new kind read as to is gone upstream and failed the consumer's check:mirrors. But pageId still resolves a control id — resolveControl( ) first, .getId( ) after — so what an app writes on the ABAP side is unchanged and still has to exist in the view. The kind records a fact about the container, not about the argument this list checks, so to belongs in CONTROL_METHOD_ID_ARG exactly as before and the derivation now admits pageId. Without this, abap2UI5 cannot merge the fix that introduced the kind: its mirror gate is red until a linter that knows about it ships.

• date-type-without-source reads the QUOTED key spelling. A binding-info may be written { 'type': 'sap.ui.model.type.Date' } as legitimately as with bare keys, and samples-controls apps 017/018 write all eight of their date bindings that way. The matcher required a bare type:, so it stopped at the first test and never judged them — blind, not wrong.

  The fix has to move both halves together, which is the whole point: the source test required a bare source: too, so teaching the rule the quoted 'type' alone would have turned those eight correct bindings into findings, because their 'source' is quoted as well. Value quotes may now be single or double for the same reason. Corpus after the change: 0 findings, total

... (truncated)

Commits

• 8ae804f release v0.5.1 — backToPage joins the id-argument mirror (#65)
• 5f03b6f release v0.5.0 — two new rules, a widened one, and a 16-entry enum-snapshot r...
• bbd9e19 release v0.4.1 - relative-aggregation-without-context on an element-bound slo...
• 813466e release v0.4.0 (#62)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions