Open tobiasqueck opened 1 year ago
Thanks a lot @tobiasqueck. This enhancement request will be covered in backlog item CPOUI5FOUNDATION-547.
Thanks a lot @tobiasqueck. This enhancement request will be covered in backlog item CPOUI5FOUNDATION-547.
Happy to hear that. Do you also have a rough timeline?
@ecker
Hi @tobiasqueck, we don't have a timeline, yet. Back then, it was clear to only be a target after UI5 Tooling 3.0 and some larger (ongoing) topics. Once we revised your topic, maybe in context of other TS enablements, we'll get back to you, thanks.
Hi! It would be really nice to have UI5 tooling covered with types. TypeScript is more than code suggestion. Moreover I see you spend quite some time in JSDoc. Using Typescript will help you to write much simpler and cleaner code and code suggestion will be only one of the features available out of the box. But since you have JSDoc - you may consider Types generation out of them.
@ThePlenkov We have this feature already in our backlog CPOUI5FOUNDATION-547. But no timeline yet when it will be available.
@flovogt thanks for a quick reply, Florian. This ticket you're referencing to - is it a public backlog or internal? Thanks!
You're welcome. Its an internal backlog managing system. Putting the backlog reference here makes our life easier to identify features are not yet prepared and planned in our internal system.
Is your feature request related to a problem? Please describe.
We as the maintainer of the in SAP Fiori tools and the Open UX tools (https://github.com/SAP/open-ux-tools) develop multiple custom tasks and middlewares. Our development language of choice is typescript, however, there are no types available for the API that is to be implemented by custom tasks and middlewares.
Describe the solution you'd like
It would be great if all the required types are part of the UI5 tooling packages
@ui5/fs
,@ui5/builder
and so on, so that I can import the types in my modules and have all the comforts of using a fully typed language.Describe alternatives you've considered
The best alternative so far is to read your documentation and manually define the types in a separate
.d.ts
file e.g.but that is of course not a good solution since we now need to make sure that our types stay in sync with your development.
Additional context
No.