abap2UI5 for VS Code

VS Code extension for developing abap2UI5 apps: launch an app with F9, see it right next to the source, and have it reload automatically when you activate the class — without the context switch to the browser. The whole abap2UI5-linter runs in the editor while you type, so a broken view is a squiggle rather than a blank screen.

Works with any system running abap2UI5 (on-premise or cloud). The only thing tying the extension to a system is the launch URL you configure once.

→ The extension, in full — F9 and the embedded preview, the auth proxy and why it exists, reload on activation, the view checks and quick fixes, completion and hover for the whole UI5 API, the systemless view preview, the refactorings, the MCP servers, what works in the browser, and every setting.

Install abap2UI5 from the VS Code Marketplace: Extensions panel (Ctrl/Cmd + Shift + X) → search for abap2UI5 → Install. Through the terminal:

code --install-extension abap2ui5.abap2ui5

On Open VSX for VSCodium, Eclipse Theia, SAP Business Application Studio and friends. Without Marketplace access, every release carries the .vsix — Extensions panel → … menu → Install from VSIX… — or build it yourself, see Packaging below.

Coming from a pre-Marketplace .vsix install? Those builds used the placeholder publisher abap2ui5-local, which makes them a different extension to VS Code — they keep working but never update. Uninstall once (code --uninstall-extension abap2ui5-local.abap2ui5), then install from the Marketplace. Settings are kept; the stored SAP credentials are asked for once again.

On the first F9 the extension asks for the launch URL, with {class} as the placeholder:

https://host:44300/sap/bc/z2ui5?app_start={class}&sap-client=100

• F9 runs the app next to the source, and the cursor stays where it was. Ctrl+F3 activates the class through your ABAP tooling and reloads the preview — activations done any other way are noticed on the server too.
• The preview is more than a browser tab: device widths, themes and languages; runtime errors forwarded into the editor; a click-the-control → jump-to-the-builder-call inspector; the live JSON model; a traffic log with roundtrip timings; headless screenshots; and a pin that carries the model across a reload.
• Static view checks while you type — the linter's property gate in process, the abap2UI5 rules with it, the render gate on demand. Quick fixes, waivers that CI honours, and a findings view grouping the repository's findings by rule. An open abaplint.jsonc whose abap2UI5 pin is below the release the bundled linter assumes gets a warning on its branch line.
• The whole UI5 API in completion and hover, plus the binding paths your class's model actually has, and the client-> API with its ABAP signature.
• Write the view faster: Format Document repairs a chain's indentation, Emmet-style abbreviations expand into one, Extract to View Method splits a long one, and Convert XML View to Builder Chain turns a demo kit sample into ABAP.
• See the view without a system — Preview View (No System) renders what the class builds, with a device matrix and a compare-with-HEAD mode.
• Test without a system — Run Unit Tests (No System) runs the app's ABAP Unit tests in the transpiled abap2UI5 backend through mcp-server's abap2ui5-unit, in a terminal, for one class or the whole src/: the editor's counterpart of npm run test:unit in a project from app-template.
• Migrate a classic report — Migrate Classic Report to abap2UI5 turns a *.prog.abap into an abap-cloud-gui report class with its converter report2cloud, opens the class beside its migration report and puts every statement it refuses into Problems (details).
• Navigate an app: the view hierarchy in the Outline pane, Go to Definition between an event and its WHEN, F2 renaming every literal an app is wired together with, and a navigation map of the workspace's apps.
• Templates: New App from Template is a gallery of linter-clean skeletons; New Project from Template writes a whole app-template project.
• For AI agents: the abap2UI5 MCP server registered for every MCP client in the window, plus a second, in-extension server holding what only the extension has — the configured systems, the credentials and the proxy (list_systems, search_apps, run_app_on_system), and, once you allow it, the app tools that let an agent operate an app on the system through its JSON protocol. Add Agent Setup to Workspace makes an existing project agent-ready: app-template's AGENTS.md, CLAUDE.md, the four skills, .mcp.json, the two gates and check.yml, from the bundled snapshot - nothing overwritten, package.json and .gitignore merged, the gates pointed at your STARTING_FOLDER, the same files as npm create abap2ui5-app@latest -- --agent-setup. The setup for every agent, the Claude Code plugin among them, is on the AI page of the documentation.
• Works in the browser — vscode.dev, github.dev and browser-based SAP Business Application Studio get the language half.

The abap2UI5 System MCP server offers four tools that operate an abap2UI5 app semantically on the active SAP system: an agent fills fields by model path or label and fires events by name, over the same JSON protocol the browser frontend speaks - no browser, no CSS selector, no screenshot. Every answer is an agent snapshot v1: the fields with their values and whether they are editable, the actions with their arguments, the tables, the messages, some static text.

They are the same tools, with the same input, snapshot and refusals, as the sandbox tools of the abap2UI5 MCP server (see its docs/agent-snapshot.md, at the vendored commit): an event that is not on the screen, a field that is not editable, a choice outside its values is refused with what is allowed, and nothing is sent. The code behind the snapshot is that server's own, vendored into src/vendor/agent/ (see Development). What differs on a real system:

• They act for real, as the configured user. An event may save, post or delete data. So the tools answer only while abap2ui5.agent.enableAppTools is on - off by default, and settable in your User settings only, never by a workspace. While it is off they stay listed and answer with how to switch them on, without contacting the system.
• The active system. Like run_app_on_system they work on the system Select System made active, through the auth proxy (the credentials stay there; the requests show in the traffic log). The optional system argument of app_list/app_start must name that system - the tools never switch. A session remembers its system, and app_act refuses it while another system is active.
• The launch URL must carry the class as a query parameter (…/sap/bc/z2ui5?app_start={class}&sap-client=100): the tools post to that endpoint without the class, as the browser posts to its own page. They handle what a browser would - a CSRF token layer in front of the system, a stateful session's sap-contextid, the system's cookies.
• app_start also accepts a namespaced class (/ns/cl_app).

Migrate Classic Report to abap2UI5 (Command Palette, or the context menu of a *.prog.abap in the editor and the Explorer) converts a classic report into a class of the abap-cloud-gui addon, which keeps the programming model of a report: the event blocks as methods, write( ), alv( ) and message( ) as calls. The converter is the addon's own report2cloud (tools/report2cloud in that repository), the same one the MCP server's migrate_report tool runs. It is not on npm, so the command runs it from a checkout of the addon:

git clone https://github.com/abap2UI5-addons/abap-cloud-gui
cd abap-cloud-gui && npm ci

and abap2ui5.report2cloud.path pointing at that folder (or the ABAP_CLOUD_GUI_HOME environment variable the MCP server reads). Without one the command says so and offers Configure…; a checkout without its npm ci gets Run npm ci. It runs with VS Code's own Node.js.

1. It asks for the class name - report2cloud's default, zcl_ + the report name, is preselected - and whether to write next to the report or into another folder; existing files of that class are only replaced after you confirm.
2. The class (.clas.abap, .clas.xml, the report's local classes as .clas.locals_def/_imp.abap) and <class>.migration.md are written in abapGit format, with the report's text pool when its .prog.xml lies beside it. The class opens with the migration report beside it - the work list of TODOs, the tables and APIs not released on ABAP Cloud with their successors, and what the list does not carry over.
3. A statement with no counterpart in a browser app (CALL SCREEN, a dynpro module, batch input, SUBMIT, native SQL, ...) is refused: each one is an error in Problems, on the statement in the report, and no class is written. Write Partial Result writes the draft anyway, the refused statements marked in it.
4. When the new class builds a view of its own, Preview View (No System) and Check Views are offered on it. A plain report class draws its screen through z2ui5_cl_cgui_report and has no view of its own to check.

A namespaced class name (/ns/cl_x) is not offered here - run report2cloud's CLI for those.

All of them are in the Command Palette (Ctrl/Cmd + Shift + P) under abap2UI5; the few with a key are the ones you reach for while typing. This reference is generated from package.json with npm run commands, and npm run commands:check fails when the two drift apart.

Everything lives under the abap2ui5. prefix. The full descriptions (with examples) are in the Settings UI; this reference is generated from package.json with npm run settings, and npm run settings:check fails when the two drift apart.

npm install
npm run compile      # builds dist/extension.js with esbuild

Open this repository in VS Code and press F5 → a second VS Code window (Extension Development Host) starts with the extension loaded.

Handy while developing: npm run watch rebuilds on every change, npm run lint runs tsc --noEmit plus eslint, and npm test runs the unit suite with node --test — several hundred tests over every vscode-free module (bundled with the same esbuild config the extension ships with), plus the cross-checks: the manifest against the registered commands, the property gate against the linter's own pipeline, the snippets and templates through the bundled linter. The in-host smoke tests (npm run test:web, npm run test:desktop) each download a VS Code build and run in CI.

The agent app tools' snapshot code is mcp-server's, vendored at a recorded commit: npm run agent-vendor -- /path/to/mcp-server [--ref <commit>] copies it into src/vendor/agent/ (and the recorded sessions its tests replay into src/test/fixtures/agent/), and npm run agent-vendor:check -- /path/to/mcp-server fails when the copies drift from that commit. npm test fails on a hand edit of a copy.

npm install
npm run vsix

The result is a file such as abap2ui5-<version>.vsix.

vsce is included as a devDependency, so npm run vsix uses the local version. Alternatively install it globally: npm install -g @vscode/vsce.

Every push and pull request builds the same .vsix in CI and attaches it to the run as an artifact — handy for trying out a branch without building it locally.

Bump version in package.json, add the matching CHANGELOG.md section, then either

• run the Release workflow from the Actions tab — it tags the current commit with v<version> and releases it, or

• tag the commit yourself:

  git tag v<version>
  git push origin v<version>

Either way the workflow builds the .vsix, creates the GitHub release and attaches the file, with the changelog section of that version as the release notes. Tag and package.json have to agree, otherwise the run fails on purpose — and a version that is already released is refused instead of overwritten.

This project is English-only. Code, comments, identifiers, commit messages, documentation, and every user-facing string in the extension are written in English — see AGENTS.md for the full conventions.

MIT — see LICENSE.