Skip to main content

Stolperfallen

Die meisten Probleme haben eine Ursache: Ein Typ, den VS Code nicht kennt, wird ohne Typprüfung still zu any. Die Annotation sieht dann richtig aus, prüft aber nichts. Diese Fälle kommen in unserem Code vor:

1. Typnamen, die es nicht gibt. ISonderfall DexDossier: Der Typ ist handgeschrieben (typings_dexpro/DexDossier.d.ts). Was die API liefert, ist ein generierter Typ wie hrdexDossier und wird per Cast zu DocFile & DexDossier.

2. Doku, die nicht zum Code passt. findSystemUserByMail in DEXPRO__FunctionLib.js gibt bei Fehlern false zurück, deklariert aber nur SystemUser:

// Falsch
 * @returns {SystemUser} System user object or boolean false
// Richtig
 * @returns {SystemUser | false} System user object or false if not found

Nur mit der richtigen Variante erinnert VS Code die Aufrufer an die false-Prüfung. Optionale Parameter gehören außerdem in eckige Klammern: @param {boolean} [caseSensitive=false].

3. Echte Fehler, die checkJs schon meldet. In DexRecord_ACT_Create.mjs wird notify.TYPE.ERROR verwendet, notify ist aber nirgends definiert. Im Fehlerfall bricht das Skript also mit einem ReferenceError ab, statt den Benutzer zu benachrichtigen. Außerdem wird file.ProjectID gelesen, obwohl file als DocFile typisiert ist, und in newRecord.ProjectId geschrieben, das dexRecord nicht kennt.

4. Bibliotheken ohne paths-Eintrag. import … from "DexNotification_API" und require("DexDossierLib") findet VS Code nicht (siehe "Voraussetzung: Modulnamen auflösen"). Alles, was daraus kommt, ist any und wird nicht geprüft.

5. @ts-ignore ohne Begründung. Ein @ts-ignore unterdrückt jeden Fehler der nächsten Zeile, auch künftige. Deshalb immer den Grund dazuschreiben, wie hier in Gadget_DEXPRO_Contract_Certs_MailNotifications.js:

// @ts-ignore - document is a browser global, lib.dom is not part of the
// project's type libs (see jsconfig.json), same for CKEDITOR/console below
roots.push(document);

In derselben Datei stehen vier @ts-ignore ohne Grund (Zeilen 672, 681, 741, 743). Das ist das Gegenbeispiel.

6. @typedef statt @type. /** @typedef {GadgetContext} gadgetContext */ legt nur einen neuen Typnamen an. Die Variable gadgetContext bleibt untypisiert. Richtig ist /** @type {GadgetContext} */ var gadgetContext;.

7. Gleiche Namen in mehreren Skripten. Skripte ohne import/export teilen sich für VS Code einen globalen Namensraum. Elf Gadget-Skripte deklarieren z.B. auf oberster Ebene const gAPI = require(...). Dann erscheint "Cannot redeclare block-scoped variable 'gAPI'", obwohl das Skript auf dem Server korrekt läuft. Projektweit sind das 185 Meldungen in 68 Dateien, am häufigsten bei ret, log und iTWOConn. Abhilfe: Den Skriptcode in eine Funktion packen (z.B. function main() { ... }), damit die Variablen lokal sind.

8. Fehler in der generierten fileTypes.d.ts. Referenzfelder auf ein Skript erzeugt der Generator als ungültiges TypeScript, z.B. "DossierReference": runscript:DexDossier_DossierReferenceScript; (7 Stellen). Der Rest der Datei funktioniert, nur diese Felder haben keinen brauchbaren Typ. Nicht von Hand korrigieren, das Problem an otris melden.

9. return auf oberster Ebene. Portalskripte dürfen auf dem Server direkt mit return enden. TypeScript meldet das als "A 'return' statement can only be used within a function body" (146 Stellen in 76 Dateien). Abhilfe wie bei Punkt 7: Code in eine Funktion packen und nur noch einmal am Ende zurückgeben, mit Begründung: // @ts-ignore - Portalskript-Rückgabe auf oberster Ebene über return main();.

Back to top