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.24 to 2.120.33

Commits

• 1dfb24a chore(release): v2.120.33 (#4240)
• 16a28d0 bugfix (#4239)
• 392e086 chore(release): v2.120.32 (#4238)
• 6962edb bugfix + rule no_dynamic_calls (#4236)
• b916298 Add XML BOM rule (#4237)
• 8369482 chore(release): v2.120.31 (#4235)
• 5462d19 bugfixes (#4234)
• 6756e89 chore(release): v2.120.30 (#4233)
• a2e264a bugfixes (#4230)
• aa639ce cloud_types: accept SMBC, TOBJ and G4BA as cloud enabled (#4231)
• Additional commits viewable in compare view

Updates @abap2ui5/linter from 0.2.2 to 0.3.0

Release notes

Sourced from @​abap2ui5/linter's releases.

v0.3.0

• The companion-control mirrors are a knowledge file now, and gated. The render harness has to KNOW a control class before it can create a view that names one, so it booted metadata-only mirrors of the two bundled abap2UI5 companion controls a view can name declaratively — written inline in lib/render.mjs, and the one mirror check-upstream did not compare. It rotted exactly the way the others did before they were gated: abap2UI5 added TokenKeyCell / TokenTextCells to MultiInputExt (the suggestion-row half of MultiInput.addValidator) and every view using them failed view CREATION here — which is worse than a property finding, because a downstream deviation can carry a property finding and cannot carry a dead document. The mirrors move to lib/cc-controls.mjs, the harness script is generated from that one source, and check-upstream compares each control's property names against app/webapp/cc/<Name>.js — in both directions, plus the case where the control is gone upstream and the mirror has no source any more.

• lib/released-api.mjs follows upstream's interface move. abap2UI5 put every type on the object that USES it — ty_s_get, ty_s_event_control and cs_device onto z2ui5_if_client, the three HTTP-config types onto z2ui5_if_ui5_exit — and retired the shared z2ui5_if_types into src/99 together with z2ui5_if_exit, the exit interface's superseded name. The mirror still said the old thing, in both damaging directions at once: z2ui5_if_ui5_exit was reported as not released (correct code, flagged), and the two retired interfaces passed as released (an app naming them told nothing). They ship, so naming one compiles — which is exactly why it has to be reported, with the object the types moved to. Measured on abap2UI5/samples-controls app 252, which named z2ui5_if_types=>cs_device: the transpiled backend answered HTTP 500 because the retired interface's constants are not materialised there, and the corpus found it in an e2e sweep. The rule reports it statically now. The corpus is otherwise unchanged by the fix: 622 ports, 0 failing, before and after.

• scripts/check-upstream.mjs is published. The three hand-maintained mirrors in lib/ — formatters.mjs, frontend-actions.mjs, released-api.mjs — are compared against abap2UI5 weekly here, which is the wrong end of that contract: the pull request that renames a formatter or splits an action module is in the other repository, green, and nothing tells it. Nothing was broken by that yet only because the drift always surfaced within the week; the mirror check had already been broken once by an upstream refactor it could not see coming. Shipping the script lets abap2UI5 run the same comparison against its own working tree, on the change that moves the source — --local, the mode it already had. No second implementation, and nothing about the script's behaviour changes for this repository.

  Consumers can call it as node node_modules/@abap2ui5/linter/scripts/check-upstream.mjs --local <dir>; it exits 0 in sync, 1 on drift and 2 when the sources cannot be read, so a caller can treat unreachable sources as a skip rather than a failure.

Changelog

Sourced from @​abap2ui5/linter's changelog.

0.3.0

• The companion-control mirrors are a knowledge file now, and gated. The render harness has to KNOW a control class before it can create a view that names one, so it booted metadata-only mirrors of the two bundled abap2UI5 companion controls a view can name declaratively — written inline in lib/render.mjs, and the one mirror check-upstream did not compare. It rotted exactly the way the others did before they were gated: abap2UI5 added TokenKeyCell / TokenTextCells to MultiInputExt (the suggestion-row half of MultiInput.addValidator) and every view using them failed view CREATION here — which is worse than a property finding, because a downstream deviation can carry a property finding and cannot carry a dead document. The mirrors move to lib/cc-controls.mjs, the harness script is generated from that one source, and check-upstream compares each control's property names against app/webapp/cc/<Name>.js — in both directions, plus the case where the control is gone upstream and the mirror has no source any more.

• lib/released-api.mjs follows upstream's interface move. abap2UI5 put every type on the object that USES it — ty_s_get, ty_s_event_control and cs_device onto z2ui5_if_client, the three HTTP-config types onto z2ui5_if_ui5_exit — and retired the shared z2ui5_if_types into src/99 together with z2ui5_if_exit, the exit interface's superseded name. The mirror still said the old thing, in both damaging directions at once: z2ui5_if_ui5_exit was reported as not released (correct code, flagged), and the two retired interfaces passed as released (an app naming them told nothing). They ship, so naming one compiles — which is exactly why it has to be reported, with the object the types moved to. Measured on abap2UI5/samples-controls app 252, which named z2ui5_if_types=>cs_device: the transpiled backend answered HTTP 500 because the retired interface's constants are not materialised there, and the corpus found it in an e2e sweep. The rule reports it statically now. The corpus is otherwise unchanged by the fix: 622 ports, 0 failing, before and after.

• scripts/check-upstream.mjs is published. The three hand-maintained mirrors in lib/ — formatters.mjs, frontend-actions.mjs, released-api.mjs — are compared against abap2UI5 weekly here, which is the wrong end of that contract: the pull request that renames a formatter or splits an action module is in the other repository, green, and nothing tells it. Nothing was broken by that yet only because the drift always surfaced within the week; the mirror check had already been broken once by an upstream refactor it could not see coming. Shipping the script lets abap2UI5 run the same comparison against its own working tree, on the change that moves the source — --local, the mode it already had. No second implementation, and nothing about the script's behaviour changes for this repository.

  Consumers can call it as node node_modules/@abap2ui5/linter/scripts/check-upstream.mjs --local <dir>; it exits 0 in sync, 1 on drift and 2 when the sources cannot be read, so a caller can treat unreachable sources as a skip rather than a failure.

Commits

• 9c4c0c8 Gate the companion-control mirrors, follow upstream's interface move — releas...
• 6828f9f Gate the snapshot pairing, refresh the icons monthly, publish check-upstream ...
• 436cbf0 Ask Dependabot monthly, and keep majors out of the routine bump (#56)
• 03df3bb Write the GitHub release from the tag that publishes it (#55)
• See full diff in compare view

Updates @abap2ui5/render-runtime from 0.2.1 to 0.3.0

Release notes

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

v0.3.0

• The companion-control mirrors are a knowledge file now, and gated. The render harness has to KNOW a control class before it can create a view that names one, so it booted metadata-only mirrors of the two bundled abap2UI5 companion controls a view can name declaratively — written inline in lib/render.mjs, and the one mirror check-upstream did not compare. It rotted exactly the way the others did before they were gated: abap2UI5 added TokenKeyCell / TokenTextCells to MultiInputExt (the suggestion-row half of MultiInput.addValidator) and every view using them failed view CREATION here — which is worse than a property finding, because a downstream deviation can carry a property finding and cannot carry a dead document. The mirrors move to lib/cc-controls.mjs, the harness script is generated from that one source, and check-upstream compares each control's property names against app/webapp/cc/<Name>.js — in both directions, plus the case where the control is gone upstream and the mirror has no source any more.

• lib/released-api.mjs follows upstream's interface move. abap2UI5 put every type on the object that USES it — ty_s_get, ty_s_event_control and cs_device onto z2ui5_if_client, the three HTTP-config types onto z2ui5_if_ui5_exit — and retired the shared z2ui5_if_types into src/99 together with z2ui5_if_exit, the exit interface's superseded name. The mirror still said the old thing, in both damaging directions at once: z2ui5_if_ui5_exit was reported as not released (correct code, flagged), and the two retired interfaces passed as released (an app naming them told nothing). They ship, so naming one compiles — which is exactly why it has to be reported, with the object the types moved to. Measured on abap2UI5/samples-controls app 252, which named z2ui5_if_types=>cs_device: the transpiled backend answered HTTP 500 because the retired interface's constants are not materialised there, and the corpus found it in an e2e sweep. The rule reports it statically now. The corpus is otherwise unchanged by the fix: 622 ports, 0 failing, before and after.

• scripts/check-upstream.mjs is published. The three hand-maintained mirrors in lib/ — formatters.mjs, frontend-actions.mjs, released-api.mjs — are compared against abap2UI5 weekly here, which is the wrong end of that contract: the pull request that renames a formatter or splits an action module is in the other repository, green, and nothing tells it. Nothing was broken by that yet only because the drift always surfaced within the week; the mirror check had already been broken once by an upstream refactor it could not see coming. Shipping the script lets abap2UI5 run the same comparison against its own working tree, on the change that moves the source — --local, the mode it already had. No second implementation, and nothing about the script's behaviour changes for this repository.

  Consumers can call it as node node_modules/@abap2ui5/linter/scripts/check-upstream.mjs --local <dir>; it exits 0 in sync, 1 on drift and 2 when the sources cannot be read, so a caller can treat unreachable sources as a skip rather than a failure.

... (truncated)

Changelog

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

0.3.0

• The companion-control mirrors are a knowledge file now, and gated. The render harness has to KNOW a control class before it can create a view that names one, so it booted metadata-only mirrors of the two bundled abap2UI5 companion controls a view can name declaratively — written inline in lib/render.mjs, and the one mirror check-upstream did not compare. It rotted exactly the way the others did before they were gated: abap2UI5 added TokenKeyCell / TokenTextCells to MultiInputExt (the suggestion-row half of MultiInput.addValidator) and every view using them failed view CREATION here — which is worse than a property finding, because a downstream deviation can carry a property finding and cannot carry a dead document. The mirrors move to lib/cc-controls.mjs, the harness script is generated from that one source, and check-upstream compares each control's property names against app/webapp/cc/<Name>.js — in both directions, plus the case where the control is gone upstream and the mirror has no source any more.

• lib/released-api.mjs follows upstream's interface move. abap2UI5 put every type on the object that USES it — ty_s_get, ty_s_event_control and cs_device onto z2ui5_if_client, the three HTTP-config types onto z2ui5_if_ui5_exit — and retired the shared z2ui5_if_types into src/99 together with z2ui5_if_exit, the exit interface's superseded name. The mirror still said the old thing, in both damaging directions at once: z2ui5_if_ui5_exit was reported as not released (correct code, flagged), and the two retired interfaces passed as released (an app naming them told nothing). They ship, so naming one compiles — which is exactly why it has to be reported, with the object the types moved to. Measured on abap2UI5/samples-controls app 252, which named z2ui5_if_types=>cs_device: the transpiled backend answered HTTP 500 because the retired interface's constants are not materialised there, and the corpus found it in an e2e sweep. The rule reports it statically now. The corpus is otherwise unchanged by the fix: 622 ports, 0 failing, before and after.

• scripts/check-upstream.mjs is published. The three hand-maintained mirrors in lib/ — formatters.mjs, frontend-actions.mjs, released-api.mjs — are compared against abap2UI5 weekly here, which is the wrong end of that contract: the pull request that renames a formatter or splits an action module is in the other repository, green, and nothing tells it. Nothing was broken by that yet only because the drift always surfaced within the week; the mirror check had already been broken once by an upstream refactor it could not see coming. Shipping the script lets abap2UI5 run the same comparison against its own working tree, on the change that moves the source — --local, the mode it already had. No second implementation, and nothing about the script's behaviour changes for this repository.

  Consumers can call it as node node_modules/@abap2ui5/linter/scripts/check-upstream.mjs --local <dir>; it exits 0 in sync, 1 on drift and 2 when the sources cannot be read, so a caller can treat unreachable sources as a skip rather than a failure.

... (truncated)

Commits

• 9c4c0c8 Gate the companion-control mirrors, follow upstream's interface move — releas...
• 627ab6b fix
• 77620af One product name, one home for the rules site, and no counts in a check name ...
• 4b32178 Fix the peer range that forbade the documented pairing, publish the rule pros...
• 3b98c30 Photograph the view instead of judging it: --screenshot (#50)
• 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