Update version number

[htammen]

Latest version number of @openui5/ts-types when running npm outdated still returns 1.60.0 But the current version is 1.65.1 Please update version number in package.json with each new version of sub package ts-types.

[bd82]

Hi @htammen

Currently only 1.60.x versions are supported.

• https://github.com/SAP/ui5-typescript#status

The 1.65.1 version was released a couple of months ago and the 1.60.0 version was released earlier this week and therefore is marked by npm as the "latest".

Because the focus is only on 1.60.x versions it is preferred that any new "npm install @openui5/ts-types" would install the latest 1.60.x of ts-types...

[htammen]

Who sets the focus and will you stop supporting typescript as of 1.60? Peter mentioned typescript support in his keynote at Ui5con this year. Thought it hence had a higher priority. Will you not generate typedefs for current versions, 1.67 and 1.68?

[bd82]

To explain we need to distinguish between the @openui5/ts-types package and the more general topic of OpenUI5 (And UI5) type signatures.

The @openui5/ts-types package is an experimental beta project meant to prove the possibility of better integration between SAP's OpenUI5 and the JavaScript ecosystem + tooling via the generation of TypeScript signatures.

I believe the @openui5/ts-types package has succeed in it's objectives.

The next step is productization of the general topic of OpenUI5/UI5 TypeScript signatures which may include:

• Releasing signatures for multiple OpenUI5 versions.
• Automatic management of the life-cycle of new signature releases.
• Improving / adding content to the generated signatures.
• Improving the input JSDoc signatures.
• Exposing the d.ts generator as an npm package for use by other (none openUI5) UI5 libraries.

The none-optimized approach

So yes, in theory we could manually manage eight branches on this repo which would correspond to relevant OpenUI5 versions currently live, and fix breaking JSDocs in the OpenUI5 repo with a long feedback loop (due to multiple repos and life-cycles involved). But that seems like a very none-optimized manner to achieve our goals...

The Strategically sound approach

Instead the scope of library versions supported by @openui5/ts-types is minimized as much as possible while we invest our resources into the more strategically sound plan of integrating into the OpenUI5 library builds (See #22). If and when we can integrate into the OpenUI5 builds, we would get the signatures "for free" with every new release of an OpenUI5 library. Additionally we will also enjoy fast feedback loops when some JSDocs changes in OpenUI5 break the generation, so the TCO of such a solution would be at least an order of magnitude smaller...

Basically I hope that in the longer term the @openui5/ts-types package would be deprecated as the Type information would be available inside existing openUI5 npm packages. (e.g @openui5/sap.m).

I cannot comment on the priorities or estimated timelines of the UI5 teams (I am not even a member of UI5 team...). But I can say that I am actively working on removing possible blockers for this UI5 build integration (See #22) and strongly promoting the topic internally.

Cheers. Shahar.

[htammen]

Hi Shahar, thank you for clarifying. I misunderstood the purpose of @openui5/ts-types. Now as I understand the strategy I will wait for future enhancements.

Bye Helmut