Skip to content

Bump the toolchain group across 1 directory with 8 updates - #7

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/toolchain-846e5f6e96
Open

Bump the toolchain group across 1 directory with 8 updates#7
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/toolchain-846e5f6e96

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 27, 2026

Copy link
Copy Markdown

Bumps the toolchain group with 8 updates in the / directory:

Package From To
@abaplint/cli 2.120.28 2.120.35
@abaplint/database-sqlite 2.11.78 2.13.40
@abaplint/runtime 2.13.22 2.13.60
@abaplint/transpiler-cli 2.13.22 2.13.60
@types/node 22.19.18 26.2.0
npm-check-updates 17.1.18 23.1.0
@abap2ui5/linter 0.2.2 0.3.0
@abap2ui5/render-runtime 0.1.1 0.3.0

Updates @abaplint/cli from 2.120.28 to 2.120.35

Commits

Updates @abaplint/database-sqlite from 2.11.78 to 2.13.40

Commits

Updates @abaplint/runtime from 2.13.22 to 2.13.60

Commits

Updates @abaplint/transpiler-cli from 2.13.22 to 2.13.60

Commits

Updates @types/node from 22.19.18 to 26.2.0

Commits

Updates npm-check-updates from 17.1.18 to 23.1.0

Release notes

Sourced from npm-check-updates's releases.

v23.1.0

Added new option: --interactiveSelect

Usage:

ncu -i --interactiveSelect [value]

Default: auto

Control which upgrades are pre-selected in interactive mode. Only applies with --interactive.

Specify auto explicitly to restore the default when another value is set in your config file.

Major version zero upgrades (e.g. 0.1.0 → 0.2.0) are only pre-selected by all, since anything may change before 1.0.0. Custom groups returned by --groupFunction are likewise only pre-selected by all.

Other Changes

... (truncated)

Changelog

Sourced from npm-check-updates's changelog.

[23.1.0] - 2026-08-23

Added new option: --interactiveSelect

Usage:

ncu -i --interactiveSelect [value]

Default: auto

Control which upgrades are pre-selected in interactive mode. Only applies with --interactive.

Specify auto explicitly to restore the default when another value is set in your config file.

Major version zero upgrades (e.g. 0.1.0 → 0.2.0) are only pre-selected by all, since anything may change before 1.0.0. Custom groups returned by --groupFunction are likewise only pre-selected by all.

Other Changes

... (truncated)

Commits
  • 6060de6 23.1.0
  • cb8b979 feat: add --interactiveSelect to control pre-selected upgrades (#2029)
  • adff18f feat(pnpm): read registries from pnpm-workspace.yaml (#1973)
  • e6fd084 Update dependencies (#2023)
  • 7711706 Remove the temp working directory created by the build-changelog tests (#2024)
  • ab09299 Add min-release-age=7 to .npmrc (#2025)
  • c68fe38 Restore CHANGELOG.md and automate release-driven changelog sync (#2014)
  • 9db5c59 Fix two rc-config tests that asserted nothing (#2020)
  • 6ddcf1a Fix crash when a dist-tag points to a version missing from the packument (#2011)
  • 1d584be Run getOwnerPerDependency at --concurrency (#2017)
  • Additional commits viewable in compare view
Install script changes

This version modifies prepare script that runs during installation. Review the package contents before updating.


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.1.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)
  • 599cecc release v0.2.1 (#48)
  • f829c9d release v0.2.0
  • 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

@dependabot
Bump the toolchain group across 1 directory with 8 updates
7d72e19 
Bumps the toolchain group with 8 updates in the / directory:

| Package | From | To |
| --- | --- | --- |
| [@abaplint/cli](https://github.com/abaplint/abaplint) | `2.120.28` | `2.120.35` |
| [@abaplint/database-sqlite](https://github.com/abaplint/transpiler) | `2.11.78` | `2.13.40` |
| [@abaplint/runtime](https://github.com/abaplint/transpiler) | `2.13.22` | `2.13.60` |
| [@abaplint/transpiler-cli](https://github.com/abaplint/transpiler) | `2.13.22` | `2.13.60` |
| [@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node) | `22.19.18` | `26.2.0` |
| [npm-check-updates](https://github.com/raineorshine/npm-check-updates) | `17.1.18` | `23.1.0` |
| [@abap2ui5/linter](https://github.com/abap2UI5/linter) | `0.2.2` | `0.3.0` |
| [@abap2ui5/render-runtime](https://github.com/abap2UI5/linter/tree/HEAD/render-runtime) | `0.1.1` | `0.3.0` |



Updates `@abaplint/cli` from 2.120.28 to 2.120.35
- [Release notes](https://github.com/abaplint/abaplint/releases)
- [Commits](abaplint/abaplint@v2.120.28...v2.120.35)

Updates `@abaplint/database-sqlite` from 2.11.78 to 2.13.40
- [Commits](https://github.com/abaplint/transpiler/commits)

Updates `@abaplint/runtime` from 2.13.22 to 2.13.60
- [Commits](https://github.com/abaplint/transpiler/commits)

Updates `@abaplint/transpiler-cli` from 2.13.22 to 2.13.60
- [Commits](https://github.com/abaplint/transpiler/commits)

Updates `@types/node` from 22.19.18 to 26.2.0
- [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases)
- [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node)

Updates `npm-check-updates` from 17.1.18 to 23.1.0
- [Release notes](https://github.com/raineorshine/npm-check-updates/releases)
- [Changelog](https://github.com/raineorshine/npm-check-updates/blob/main/CHANGELOG.md)
- [Commits](raineorshine/npm-check-updates@v17.1.18...v23.1.0)

Updates `@abap2ui5/linter` from 0.2.2 to 0.3.0
- [Release notes](https://github.com/abap2UI5/linter/releases)
- [Changelog](https://github.com/abap2UI5/linter/blob/main/CHANGELOG.md)
- [Commits](abap2UI5/linter@v0.2.2...v0.3.0)

Updates `@abap2ui5/render-runtime` from 0.1.1 to 0.3.0
- [Release notes](https://github.com/abap2UI5/linter/releases)
- [Changelog](https://github.com/abap2UI5/linter/blob/main/CHANGELOG.md)
- [Commits](https://github.com/abap2UI5/linter/commits/v0.3.0/render-runtime)

---
updated-dependencies:
- dependency-name: "@abaplint/cli"
  dependency-version: 2.120.35
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: toolchain
- dependency-name: "@abaplint/database-sqlite"
  dependency-version: 2.13.40
  dependency-type: direct:development
  update-type: version-update:semver-minor
  dependency-group: toolchain
- dependency-name: "@abaplint/runtime"
  dependency-version: 2.13.60
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: toolchain
- dependency-name: "@abaplint/transpiler-cli"
  dependency-version: 2.13.60
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: toolchain
- dependency-name: "@types/node"
  dependency-version: 26.2.0
  dependency-type: direct:development
  update-type: version-update:semver-major
  dependency-group: toolchain
- dependency-name: npm-check-updates
  dependency-version: 23.1.0
  dependency-type: direct:development
  update-type: version-update:semver-major
  dependency-group: toolchain
- dependency-name: "@abap2ui5/linter"
  dependency-version: 0.3.0
  dependency-type: direct:development
  update-type: version-update:semver-minor
  dependency-group: toolchain
- dependency-name: "@abap2ui5/render-runtime"
  dependency-version: 0.3.0
  dependency-type: direct:development
  update-type: version-update:semver-minor
  dependency-group: toolchain
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file javascript Pull requests that update javascript code labels Aug 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file javascript Pull requests that update javascript code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants