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 kommentreten in unseremDOCUMENTS-Projekten Codetypischerweise vor:auf:

1. Typnamen, die es nicht gibt. ISonderfallEin Mappentyp heißt in DexDossierfileTypes.d.ts: Derwie sein technischer Name, nicht wie seine Bezeichnung in der Oberfläche. Ein @type {Projekt} für den Mappentyp crmProject ergibt "Cannot find name 'Projekt'". Typnamen also immer per Autovervollständigung einfügen. Handgeschriebene Typen, etwa ein gemeinsamer Typ istfür handgeschriebenmehrere (typings_dexpro/DexDossier.d.ts).Mappentypen, passen nicht automatisch zu den generierten: Was die API liefert, ist ein generierter Typ wie hrdexDossier und wird per Cast zueingegrenzt (DocFile & DexDossierMeinTyp).

2. Doku, die nicht zum Code passt. findSystemUserByMailTypisch inist DEXPRO__FunctionLib.jseine gibtFunktion, die bei Fehlern false zurück, deklariertzurückgibt, aber nur SystemUser:den Erfolgsfall deklariert:

// 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. InHäufig DexRecord_ACT_Create.mjssind wirdVariablen, notify.TYPE.ERROR verwendet, notify ist aberdie nirgends definiert.definiert Imsind Fehlerfall(z.B. brichtnach einem vergessenen Import), und Felder, die der Mappentyp nicht kennt (ein Tippfehler im Feldnamen oder ein Feld, das Skriptnur alsoein mitanderer einemMappentyp hat). Auf dem Server fallen beide erst zur Laufzeit auf, als ReferenceError ab, statt den Benutzer zu benachrichtigen. Außerdem wird file.ProjectID gelesen, obwohl fileoder als DocFileleerer typisiert ist, und in newRecord.ProjectId geschrieben, das dexRecord nicht kennt.Wert.

4. Bibliotheken ohne paths-Eintrag. Wird eine eigene Bibliothek per Name geladen (require("MeineLib") oder import … from "DexNotification_API"MeineLib"), braucht sie einen Eintrag unter paths. Sonst ist alles daraus any und require("DexDossierLib") findet VS Code nichtungeprüft (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:dazuschreiben:

// @ts-ignore - document isist aein browser global,Browser-Global, lib.dom isist notin part of theder
// project'sjsconfig.json typebewusst libsnicht (see jsconfig.json), same for CKEDITOR/console beloweingebunden
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. ElfDeklarieren Gadget-zwei Skripte deklarieren z.B. auf oberster Ebene z.B. const gAPI = require(...). Dann, erscheint "Cannot redeclare block-scoped variable 'gAPI'", obwohl das Skriptbeide auf dem Server korrekt läuft. Projektweit sind das 185 Meldungen in 68 Dateien, am häufigsten bei ret, log und iTWOConn.laufen. Abhilfe: Den Skriptcode in eine Funktion packen (z.B. function main() { ... }), damit die Variablen lokal sind.

8. Fehler in der generierten fileTypes.d.ts. ReferenzfelderReferenzfelder, aufdie ihre Auswahl über ein Skript beziehen, erzeugt der Generator als ungültiges TypeScript, z.B. "DossierReference"Kunde": runscript:DexDossier_DossierReferenceScript;MeinReferenzSkript; (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