Bump the toolchain group with 6 updates

[dependabot]

Bumps the toolchain group with 6 updates:

Package	From	To
@abaplint/cli	2.120.35	2.120.40
@abaplint/runtime	2.13.60	2.13.64
@abaplint/transpiler-cli	2.13.60	2.13.64
@types/node	26.3.0	26.4.1
@abap2ui5/linter	0.4.1	0.6.1
@abap2ui5/render-runtime	0.4.1	0.6.1

Updates @abaplint/cli from 2.120.35 to 2.120.40

Commits

• c9e292e chore(release): v2.120.40 (#4259)
• f6e85ff FORMs fix (#4245)
• 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)
• See full diff in compare view

Updates @abaplint/runtime from 2.13.60 to 2.13.64

Commits

• See full diff in compare view

Updates @abaplint/transpiler-cli from 2.13.60 to 2.13.64

Commits

• See full diff in compare view

Updates @types/node from 26.3.0 to 26.4.1

Commits

• See full diff in compare view

Updates @abap2ui5/linter from 0.4.1 to 0.6.1

Release notes

Sourced from @​abap2ui5/linter's releases.

v0.6.1

See CHANGELOG.md.

v0.6.0

See CHANGELOG.md.

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

... (truncated)

Changelog

Sourced from @​abap2ui5/linter's changelog.

0.6.1 - 2026-08-30

• A bound control in a FOREIGN namespace makes its children rows again. The property walk declines to look into a non-sap. namespace - abap2UI5's own z2ui5.cc controls, raw XHTML, any in-house library - because the UI5 metadata can say nothing about it. It handed the children null for both owner and context, and "no aggregation here" quietly became "no ROW here":

  <z2ui5:CameraSelector items="{path:'/DEVICES'}">
    <core:Item key="{KEY}" text="{TEXT}"/>
  

  is the ordinary bound-template form, and relative-binding-without-context reported both attributes as resolving against nothing (abap2UI5/samples app 306). Every one of these controls extends a real one - CameraSelector extends sap.m.ComboBox and inherits its items - so this fires on any bound custom control, as an error.

  The owner handed across stays opaque in every other respect (control: null, empty aggRows), so nothing guesses at an aggregation, which is what the foreign-namespace rule is actually protecting. Any binding on the tag counts, not only one that looks like an aggregation: on a control the metadata does not carry the two are indistinguishable, and being wrong is asymmetric - reading a property binding as a context only makes the two "is there a context here" rules go quiet on that subtree, while reading a real aggregation binding as none invents a defect.

  A foreign tag with no binding still opens no context, and its children are judged exactly as before; the regression test asserts both directions. Measured: no change over abap2UI5/samples-controls (752 findings before and after), which is the corpus with no custom controls in it.

0.6.0 - 2026-08-30

• WITH DEFAULT KEY parses, and the rules that resolve against a row see something again. A table declaration is anchored on its terminating dot, and only WITH EMPTY KEY was allowed in front of it — so DATA t TYPE STANDARD TABLE OF ty WITH DEFAULT KEY, the commonest spelling in ABAP, fell through to the scalar branch: the model carried '' where a row array belongs, and every rule resolving against a ROW went quiet on it. SORTED and HASHED tables were not recognized as tables at all. This outranks any single rule below, because it decides whether those rules see anything.

• 17 new rules, mined from what was already written down. The frontend's own declarations are read in full now rather than in projections: control-call-arg-count and control-call-arg-kind (arity and argument kinds, from the whole method map), frontend-action-too-new — a global target resolved through a lazy require is silent below its release, and member-too-new judged what the view writes while nothing judged what the class sends — and invalid-aggregation-item, where an <id>/<aggregation>/<index> reference was judged on its head segment only.

... (truncated)

Commits

• 798d520 release v0.6.1
• 5f736ec Give a bound control in a foreign namespace its row context back (#82)
• d42d70e release v0.6.0
• 7263cb5 Read a chained DATA: past its first name in the two section collectors (#81)
• f16f4cc Mine the staging areas: 17 rules, a metadata harvest and a reconstructor fix ...
• e8c7b93 Reconstruct the _bind cell binding instead of dropping its attribute (#79)
• 602494c Read abap2UI5's arg shorthand in the two event-argument rules (#78)
• 89013ce Three places where the escaping stops one character short (#77)
• 674b183 The third windows-latest failure, plus a check that checks and timeouts on ...
• b0efc6d Two of the three windows-latest failures, and a drift gate that names the dri...
• Additional commits viewable in compare view

Updates @abap2ui5/render-runtime from 0.4.1 to 0.6.1

Release notes

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

v0.6.1

See CHANGELOG.md.

v0.6.0

See CHANGELOG.md.

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

... (truncated)

Changelog

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

0.6.1 - 2026-08-30

• A bound control in a FOREIGN namespace makes its children rows again. The property walk declines to look into a non-sap. namespace - abap2UI5's own z2ui5.cc controls, raw XHTML, any in-house library - because the UI5 metadata can say nothing about it. It handed the children null for both owner and context, and "no aggregation here" quietly became "no ROW here":

  <z2ui5:CameraSelector items="{path:'/DEVICES'}">
    <core:Item key="{KEY}" text="{TEXT}"/>
  

  is the ordinary bound-template form, and relative-binding-without-context reported both attributes as resolving against nothing (abap2UI5/samples app 306). Every one of these controls extends a real one - CameraSelector extends sap.m.ComboBox and inherits its items - so this fires on any bound custom control, as an error.

  The owner handed across stays opaque in every other respect (control: null, empty aggRows), so nothing guesses at an aggregation, which is what the foreign-namespace rule is actually protecting. Any binding on the tag counts, not only one that looks like an aggregation: on a control the metadata does not carry the two are indistinguishable, and being wrong is asymmetric - reading a property binding as a context only makes the two "is there a context here" rules go quiet on that subtree, while reading a real aggregation binding as none invents a defect.

  A foreign tag with no binding still opens no context, and its children are judged exactly as before; the regression test asserts both directions. Measured: no change over abap2UI5/samples-controls (752 findings before and after), which is the corpus with no custom controls in it.

0.6.0 - 2026-08-30

• WITH DEFAULT KEY parses, and the rules that resolve against a row see something again. A table declaration is anchored on its terminating dot, and only WITH EMPTY KEY was allowed in front of it — so DATA t TYPE STANDARD TABLE OF ty WITH DEFAULT KEY, the commonest spelling in ABAP, fell through to the scalar branch: the model carried '' where a row array belongs, and every rule resolving against a ROW went quiet on it. SORTED and HASHED tables were not recognized as tables at all. This outranks any single rule below, because it decides whether those rules see anything.

• 17 new rules, mined from what was already written down. The frontend's own declarations are read in full now rather than in projections: control-call-arg-count and control-call-arg-kind (arity and argument kinds, from the whole method map), frontend-action-too-new — a global target resolved through a lazy require is silent below its release, and member-too-new judged what the view writes while nothing judged what the class sends — and invalid-aggregation-item, where an <id>/<aggregation>/<index> reference was judged on its head segment only.

... (truncated)

Commits

• 798d520 release v0.6.1
• d42d70e release v0.6.0
• 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...
• 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