TL;DR

This table means:

• If you're staying on TypeScript 5.x, nothing changes — except that you should switch from @types/openui5 to @openui5/types at some time in 2026 at your convenience.
• If you're upgrading to TypeScript 6.x, also nothing changes from UI5 perspective: the UI5 types and tooling work fine. But you'll need to deal with the general TS6 tsconfig migration that every TypeScript project faces.
• TypeScript 7.x is not supported by @ui5/ts-interface-generator right now, but otherwise everything behaves like TS6.

Independently, in case you still use @sapui5/ts-types-esm or @openui5/ts-types-esm, replace with the identical @sapui5/typesor @openui5/types as the former are no longer released now.

What's Happening in the TypeScript World

TypeScript is going through a significant transition:

TypeScript 6 (released March 2026) is the last JavaScript-based TypeScript compiler. It's a bridge release: settings that were deprecated with a gentle warning before now cause hard errors. You can silence them with "ignoreDeprecations": "6.0" in your tsconfig — but the message is clear: adapt now, because these settings will truly disappear in TS7.

TypeScript 7 is a complete rewrite of the compiler in Go. The headline number: roughly 10x faster compilation. The catch: the entire JavaScript-based compiler API — ts.createProgram, ts.factory, ts.TypeChecker, everything that external tooling like ours builds upon — simply does not exist (at least not yet). There is no programmatic API for tools yet. The TypeScript team has indicated this will come in later 7.x releases, but there is no timeline.

TypeScript 6 will be maintained “until TS7 reaches sufficient maturity,” making it the thing to use for the foreseeable future.

The TS6 Changes That Affect Your tsconfig

If you're planning to upgrade your project to TypeScript 6, here are the settings that now cause hard errors:

All of this is a general TypeScript 6 migration concern. Every TypeScript project faces it, regardless of whether it uses UI5 or not. But that last point — the end of auto-discovery — has a specific consequence for us.

Deprecating @types/openui5 in Favor of @openui5/types

You might be wondering why @types/openui5 exists alongside @openui5/types in the first place. The answer: convenience. Packages under the @types/ namespace on npm are special in TypeScript — they are automatically discovered and included without any configuration. Install @types/openui5, and TypeScript just finds the UI5 type declarations. No tsconfig changes, no explicit references.

With TypeScript 6, that convenience disappears. The types field now defaults to [], meaning nothing is auto-discovered — not even @types/* packages. You have to explicitly list every type package you need. And once you have to explicitly configure it anyway, there is no longer a reason to prefer @types/openui5 over the basically identical @openui5/types. Plus, the release process of the former via DefinitelyTyped, as they own that prefix has been… complicated.

We are therefore deprecating @types/openui5. The package will continue to be published for at least the remainder of 2026, so there is no immediate rush. But we encourage you to switch to @openui5/types soon at your convenience — it's the package we maintain directly and will be the sole one going forward.

How to switch

The migration is straightforward:

1. Replace the dependency in your package.json:

npm uninstall @types/openui5
npm install --save-dev @openui5/types

2. Update your tsconfig.json:

If you previously had @types/openui5 working via auto-discovery (no types field in your tsconfig), or if you had "types": ["openui5"], change to:

{
  "compilerOptions": {
...
    "types": ["@openui5/types"]
  }
}

That's it. The type declarations are practically identical. Your code doesn't change, only the package name and the tsconfig entry.

Note: If you're on TypeScript 5.x, you don't strictly need to change right now. But once you upgrade to TS6 or you want to consume newer versions of the UI5 type definitions beyond 2026, you'll need to make this change anyway — so it's a good idea to do it proactively.

Using UI5 Type Definitions

Types-related package switch aside, here's the good news: the type definitions themselves are completely unaffected by the TS6/7 transition.

Why? Because the types use ambient module declarations:

declare module "sap/m/Button" {
  // ...
}

This is fundamental TypeScript syntax, stable since TypeScript 2, resolved by simple string matching. It doesn't depend on module resolution strategy, compiler architecture, or any deprecated feature. It just continues to work.

So if you're upgrading to TS6 or beyond, you don't need new types, you don't need to regenerate anything. What you will need to do is adjust your tsconfig.json, because TypeScript itself now rejects some settings:

• Replace "moduleResolution": "node" — we recommend "bundler" as it works without requiring file extensions on relative imports and is available since TS 5.0. Apart from that, "node16" and "nodenext" works as well.
• Add a types field listing the packages you need (see section above).

But again: these are steps you'd take for any TS6 upgrade. Nothing UI5-specific here.

Using @ui5/dts-generator

If you generate type definitions for your own UI5 library (rather than consuming the ready-made ones we publish), you're using the dts-generator. It bundles its own TypeScript internally — it is completely isolated from whatever TypeScript version lives in your project and will continue to use its internal TS6 dependency even if your project uses TS7. The generated output is version-agnostic: same ambient declarations, regardless of whether the generator runs TS5 or TS6 under the hood.

What did change: We dropped support for Node.js 16 and 18. If you run the dts-generator in your own build pipeline, you now need Node.js 20 or higher. Given that Node 18 reached end-of-life more than a year ago, this should not come as a surprise.

Using @ui5/ts-interface-generator

This is the tool most affected by the TypeScript transition: the interface generator is deeply integrated with the TypeScript compiler API. It constructs AST nodes via ts.factory, observes file changes through ts.createWatchProgram, and resolves types using ts.TypeChecker etc. These APIs still exist in TypeScript 6, but they do not exist in TypeScript 7.

On TypeScript 5.x: Nothing changes.

On TypeScript 6: Same — fully supported. We verified that all compiler API methods the tool uses are present and functionally identical in TS6.

On TypeScript 7: Explicitly not supported. We've capped the peer dependency at <7.0.0. Once TypeScript 7 publishes to npm as typescript@7.x, you'll receive a clear peer dependency warning.

What's our plan for TS7?

• Medium-term: We're evaluating bundling our own TypeScript (similar to how the dts-generator does it), which would decouple the tool from your project's TS version entirely but come with some drawbacks.
• Long-term: When TypeScript 7.x ships a stable programmatic API, we'll evaluate a rewrite of the compiler integration.

Completely Independent but also Happening Now

In UI5 1.90.x times, years ago, when the new improved TypeScript support using ES modules (instead of the globals used until then), we called the new type packages @sapui5/ts-types-esm to differentiate them from the prior @sapui5/ts-types. Soon we renamed the new packages to.@sapui5/types for simplicity, but kept releasing the ts-types-esm variants, marked as deprecated. Now we finally stop shipping the variant with the longer name, so in case you still use @sapui5/ts-types-esm or @openui5/ts-types-esm, replace with the identical @sapui5/typesor @openui5/types.

All in all, What Should You Do?

Staying on TypeScript 5.x? Switch from @types/openui5 to @openui5/types when you get a chance. Everything else stays the same.

Upgrading to TypeScript 6? Update your tsconfig (module resolution, types field) as part of the general TypeScript 6 update procedure, switch to @openui5/types if you haven't yet, and everything else just works.

Eyeing TypeScript 7? The types will work from day one. For tooling (like@ui5/ts-interface-generator) — not just ours, but across the entire TypeScript ecosystem — the community needs time to adapt to the new architecture. We're watching the developments closely.

Still using @…ui5/ts-types-esm? Switch to @…ui5/types.