npm Packages ​

abap2UI5 itself is ABAP and needs no npm at all. The packages below are the tooling around it and the ways to run it outside an SAP system. This page is the map: what each one is for, which ones build on each other, and which versions go together. The versions themselves are on npm; the rules that decide which ones fit are here.

The packages ​

The VS Code extension is not on npm but on the Marketplace. It bundles the linter and starts the MCP server.

How they depend on each other ​

@abap2ui5/linter ──optional peer──▶ @abap2ui5/linter-render
       ▲
       ├── peer (one minor) of @abap2ui5/mcp-server
       └── read by the VS Code extension

@abap2ui5/node-runtime ◀──exact pin── @cap2ui5/cds-plugin ◀──peer── @cap2ui5/samples

@abap2ui5/embed-control ──talks HTTP to──▶ abap2UI5 on ABAP, node-runtime or the CAP plugin

@abap2ui5/bsp ── depends on nothing; the embed control's CI uses it to write the BSP of its examples

Which versions go together ​

• node-runtime and the framework. The version of @abap2ui5/node-runtime is the framework's version, and it is built from that release's tag. Its @abaplint/runtime is pinned to the version the transpile ran with, because transpiled code is tied to its runtime.
• The BSP tool shares that version. @abap2ui5/bsp is published from the same release tag as @abap2ui5/node-runtime and carries the framework's version. It depends on nothing, and nothing pins it.
• The CAP plugin pins one node-runtime. @cap2ui5/cds-plugin depends on exactly one @abap2ui5/node-runtime version, the one its tests ran against. A project that wants another one says so with npm overrides; the log line at startup names the version that was loaded.
• The samples follow the plugin's minor. While the plugin is 0.x, a minor release may change how apps are written. @cap2ui5/samples therefore names the plugin's minor as its peer range and is released together with it.
• The linter and its render runtime share a minor. @abap2ui5/linter accepts the @abap2ui5/linter-render versions of its own minor. The render runtime pins the OpenUI5 version the linter's metadata was generated from. Its old name, @abap2ui5/render-runtime, is deprecated.
• The embed control needs abap2UI5 1.145.0 or later on the server, on ABAP as well as through node-runtime or the CAP plugin. Its README lists what 1.145.0 does not do yet.
• The MCP server is coupled to the linter's minor, and to nothing else. It declares @abap2ui5/linter as a peer, and @abap2ui5/linter-render as an optional one, in the range of one linter minor (>=0.8.0 <0.9.0 today), and npm installs the linter with it; a linter of another minor in a project makes npm install refuse with ERESOLVE until the server moves its range. It finds the linter next to it (a sibling checkout, AI_VIEW_CHECK_HOME, or the project's node_modules) and takes the framework from the newest plain release. The VS Code extension starts it without a version pin.

Starting the command-line tools ​

Every command-line tool here lives in a scoped package, so its command has a different name than its package. Run it through the scoped name, so npx can never fetch an unrelated package that happens to carry the command's name:

The translator reads ABAP with @abaplint/core, which is an optional peer of the plugin: a project that translates adds it with npm add -D @abaplint/core.

The BSP tool has three commands: app2bsp writes an app folder as the abapGit repository of a BSP, bsp2app turns a serialized BSP back into an app folder, and check holds a BSP to the page rules (names the system accepts, no line over 255 characters). Its README has the options, and the same functions are exported for a script.