Types within @sapui5/ts-types are invalid

Hi,

I wanted to try out TypeScript and UI5 but so far was not able to compile my projects due to 76 type errors of the @sapui5/ts-types module. Thought the problem is on my end, but so far it seems that types inside the @sapui5/ts-types are wrong? I tested with @sapui5/ts-types versions 1.84.4 (76 errors), 1.85.2 (80 errors) and 1.78.17 (2 errors). I didn’t test more versions, but it seems the tests are never quite run before publishing the modules?

Even if I run the test script of node_modules/@sapui5/ts-types module, I get the same errors: Can somebody tell me what’s up? Do I need more dependencies or are the type definition files really that buggy? Is there a types version which work?

Cheers

> @sapui5/ts-types@1.84.4 test \node_modules\@sapui5\ts-types
> tsc

types/sap.ca.ui.d.ts:5419:23 - error TS2304: Cannot find name 'FileSize'.

5419               oValue: FileSize
                           ~~~~~~~~

types/sap.f.d.ts:11720:7 - error TS2416: Property 'getGridLayoutConfiguration' in type 'GridList' is not assignable to the same property in base type 'IGridConfigurable'.
  Type 'undefined' is not assignable to type '() => GridLayoutBase'.

11720       getGridLayoutConfiguration: undefined;
            ~~~~~~~~~~~~~~~~~~~~~~~~~~

types/sap.gantt.d.ts:4849:21 - error TS2430: Interface '$RelationshipSettings' incorrectly extends interface '$PathSettings'.
  Types of property 'selectedShape' are incompatible.
    Type 'SelectedRelationship | undefined' is not assignable to type 'SelectedShape | undefined'.
      Type 'SelectedRelationship' is missing the following properties from type 'SelectedShape': getHeight, setHeight

4849           interface $RelationshipSettings
                         ~~~~~~~~~~~~~~~~~~~~~

types/sap.gantt.d.ts:17630:34 - error TS2724: 'sap.gantt.simple' has no exported member named '$BaseDiamondSettings'. Did you mean '$AdhocDiamondSettings'?

17630         extends sap.gantt.simple.$BaseDiamondSettings {
                                       ~~~~~~~~~~~~~~~~~~~~

types/sap.m.d.ts:25507:11 - error TS2559: Type 'Button' has no properties in common with type 'IFormContent'.

25507     class Button extends sap.ui.core.Control
                ~~~~~~

types/sap.m.d.ts:26829:11 - error TS2559: Type 'CheckBox' has no properties in common with type 'IFormContent'.

26829     class CheckBox extends sap.ui.core.Control
                ~~~~~~~~

types/sap.m.d.ts:40654:11 - error TS2559: Type 'Image' has no properties in common with type 'IFormContent'.

40654     class Image extends sap.ui.core.Control


........

types/sap.viz.d.ts:36:36 - error TS2694: Namespace 'sap.viz.ui5.api.env' has no exported member 'Format'.

36             ): sap.viz.ui5.api.env.Format;
                                      ~~~~~~


Found 76 errors.

npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! @sapui5/ts-types@1.84.4 test: `tsc`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the @sapui5/ts-types@1.84.4 test script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm WARN Local package.json exists, but node_modules missing, did you mean to install?

[codeworrior]

We’re still in the process of defining the mapping from UI5 APIs to TypeScript. Not all compile errors that you see are “errors” in our metadata. Most IFormContent errors for example are not due to errors in the original sources. They’re rather caused by a different understanding of interfaces in UI5 (uses several tag interfaces) and TypeScript (does no longer allow tag interfaces).

Once we’re done with the conceptual work for the mapping, we’ll adapt the generation and clean-up issues in the sources, or, where this is not possible due to compatibility constraints in UI5, will exclude the corresponding APIs from the ts-types generation. From that point in time on, new errors will break our builds and won’t go “unnoticed” (we already check the results at build time, but don’t break the build yet).

I know this isn’t perfect but a) do we currently mainly target the language server b) do we work on a better solution and c) a possible workaround exists with skipLibChecks. And, last but not least, are these some of the reasons why this project is still in Beta State .

We’ll nevertheless discuss whether we’ll go the extra mile to exclude all erroneous APIs for now.
@petermuessig , @akudev what do you think?

[bd82]

@codeworrior I reviewed #217