Mit der zunehmenden Popularität von TypeScript denke ich, dass dies geschehen muss. Viele andere js-Pakete enthalten jetzt ihre eigenen (offiziellen) Typisierungen. Anstatt es der DefinitelyTyped- Community zu überlassen

Dies ist etwas, das wir in Betracht ziehen. Es sollte möglich sein, ein Node-Skript zu erstellen, um es automatisch aus unserem API-Dump zu generieren.

+1 👍 auch von mir. Das DefinitelyTyped Repo ist veraltet, wo nach Highcharts v4.2.x nur sporadische und zufällige Eigenschaften aktualisiert wurden. Aber die meisten Änderungen in Highcarts werden einfach nicht verarbeitet.

Daher sollte entweder das DefinitelyTyped-Repository aktualisiert werden oder - bequemer - es mit Highcharts gebündelt zu haben, wäre sogar eine viel schönere Lösung.

Die automatische Generierung klingt nach einer großartigen Option, aber dies erfordert möglicherweise immer noch manuelle Arbeit beim Schreiben von Tests für die .d.ts-Datei? Es könnte auch sein, dass es automatisch generiert wird.

Ich wäre bereit, das DefinitelyTyped-Repository auf die aktuelle Version zu aktualisieren und eine PR auf https://github.com/highcharts/highcharts zu machen, wenn Sie die manuelle Datei dort

/cc @ry8806 @TorsteinHonsi

^ Ich habe eine PR für das DefinitelyTyped- Repository erstellt ,

Es wäre sehr wünschenswert, offizielle TypeScript-Typdefinitionen zu haben. Hilft sehr beim Eintippen einer Diagrammkonfiguration.

Hier sind wir mit den Typdefinitionen wieder eine große Version hinter der Realität. :/

Angesichts der Komplexität dieser Bibliothek denke ich, dass die beste Lösung darin besteht, die Typdefs aus dem "API-Dump" zu generieren, auf den sich @TorsteinHonsi bezog. Dieser Link scheint jedoch defekt zu sein. Gibt es einen neuen? Ich wäre bereit, einen Versuch zu machen, einen Generator zu schreiben.

Dieser Link scheint jedoch defekt zu sein. Gibt es einen neuen?

Ja, das neue ist unter https://api.highcharts.com/highcharts/tree.json verfügbar

@cvasseng Zur Info .

@TorsteinHonsi Danke ich werde mir das mal anschauen. Verwenden Sie eine bestimmte Variante von "jsdoc" (Google Closure, JSDoc 3?) Findet der JSON-Dump irgendwo in dieser Codebasis statt, die ich als Referenz ansehen kann? Der Grund, warum ich frage, ist, dass es existierende JSDoc-to-TSDef-Konverter gibt, die funktionieren könnten ...

Wir verwenden JSDoc 3, aber stark erweitert, um unsere deklarative Optionsstruktur beschreiben zu können.

@TorsteinHonsi Wenn ich mir den JSON Das habe ich gesammelt . Wie legen Sie Optionen fest, die an Highcharts.setOptions() Vergleich zu Highcharts.chart() (zum Beispiel) übergeben werden? Gibt es auch einen API-Dump für die Klassen und Namespaces?

@cvasseng

Hallo @aaronbeall , wir haben derzeit keine gründliche Dokumentation zum Schema, aber es sieht so aus, als ob Sie alles in Ihrer Definition enthalten haben.

Die Optionen für Highcharts.setOptions() und die Serie werden beide als Sonderfälle außerhalb des Schemas selbst behandelt, in dem wir sie verwenden, aber wir sollten mindestens global und lang ändern in außerhalb der Hauptoptionsstruktur.

Als Randnotiz war das alte Dump-Format unter https://api.highcharts.com/dump.json verfügbar, wir haben es jetzt wieder an die ursprüngliche Position unter https://api.highcharts.com/highcharts/ verschoben.

Danke @cvasseng. Ich fange an, daran herumzubasteln... es gibt viele Daten, ich habe meine Arbeit für mich, nur um alles zu verstehen. :) Mir ist aufgefallen, dass einige Felder keinen Typ haben und keinen Standardwert haben, um den Typ abzuleiten, wie z. B. boost.seriesThreshold , der Typ wird jedoch in den Dokumenten angezeigt . Werden diese als Sonderfall behandelt oder übersehe ich etwas? Gibt es auch ein API-Schema für die Namespaces/Klassen oder wird das separat behandelt? Soll das deklarative Modell diese überflüssig machen?

(Ich werde noch mehr Fragen haben, gibt es einen besseren Ort, um das zu diskutieren? Gitter? Mir geht es hier gut, aber es verursacht wahrscheinlich für einige Leute ziemlich viel Lärm.)

Der Typ für boost.seriesThreshold scheint in tree.json (und in den Live-Dokumenten) tatsächlich falsch zu sein - es soll eine Zahl sein, kein String. Betrachtet man das eigentliche Doclet, aus dem es generiert wurde, fehlt der Typ. Dies ist wahrscheinlich auch für alle anderen Orte der Fall, an denen Typen fehlen. Wir arbeiten daran, dem Generierungsdurchlauf weitere Tests und Prüfungen hinzuzufügen, um diese automatisch zu finden, wenn sich die Doclets ändern, um dies zu verhindern.

Wir haben kein Schema für Namespaces/Klassen, aber diese werden von Vanilla JSDoc 3 behandelt, sodass es möglicherweise möglich ist, ein vorhandenes Plugin hinzuzufügen, um automatisch Typoskriptdefinitionen für sie zu generieren. Das Setup für diesen Teil finden Sie hier: https://github.com/highcharts/highcharts-docstrap

Und das hier zu diskutieren funktioniert prima. :) Damit haben wir einen zentralen öffentlichen Platz dafür, damit auch andere ihm folgen können.

Falls es hilfreich ist, ist dies ein Dump aller Felder (in highcharts/tree.json), die keinen Typ zu haben scheinen. Ein kurzer Scan über die abgeleiteten Typen aus den Standardwerten (String, Zahl, Boolean) sieht für mich richtig aus, aber die, die sagen "Typ kann nicht bestimmt werden" bedeuten, dass ich keine type Eigenschaft oder default Eigenschaft, daher ist sie any zugewiesen. Ich könnte eine Patch-Datei für diese Typen schreiben, oder gibt es einen besseren Weg?

Es gibt auch einen leeren Schlüssel im JSON der obersten Ebene und in mapNavigation.buttons .

Ich habe heute einige Fortschritte gemacht, Sie können hier sehen, was derzeit generiert wurde . Es gibt noch viel Arbeit, um diese hohe Qualität herzustellen. Ich werde morgen auf ein Repo schieben. Auf hoher Ebene einige Probleme, auf die ich gestoßen bin:

• Nicht sicher, wie die Ausgabe organisiert werden soll. Im Moment gibt es 559 Symbole, die wichtige Dinge wie Highcharts.Options und Series bis hin zu ganz bestimmten kleinen Objekten wie PlotOptionsBbTopLine . Um Namenskonflikte zu vermeiden, wandelt es den vollständigen Namen in PascalCase um, zB von plotOptions.bb.topLine . Versuche immer noch herauszufinden, wie man das besser machen kann. Der Versuch, mit den aktuellen @types/highcharts ist ein bisschen schwierig, meistens gibt es dort einfach nichts.
• Ich bin mir nicht sicher, ob ich die Beziehung zwischen Highcharts/Highstocks/Highmaps verstehe. (Ich habe nur Highcharts persönlich verwendet.) Enthält der API-Dump alle Daten aller Produkte? Wie soll es aufgeteilt werden? Ich muss besser verstehen, wie man highstock und highmaps tatsächlich in einem Projekt verwendet...
• Die Art und Weise, wie sich Objekte gegenseitig erweitern, macht durchaus Sinn, aber ich habe Schwierigkeiten, herauszufinden, wie man sie in sinnvolle Typen umwandelt. Im Moment werden Objekte mit & Kreuzungstypen zusammengeführt, weil extends viele Fehler über inkompatible Erweiterungen verursacht hat. Momentan gibt es keine Behandlung von excludes , ich habe angefangen mit dem Omit Typ zu spielen, aber das führte zu vielen Fehlern über ausgelassene Felder, die im Typ nicht vorhanden sind. Ich denke, dies liegt daran, dass in einigen Fällen eine Objekteigenschaft indirekt vom übergeordneten Objekt erbt, sodass sie nicht über die Felder verfügt, die ausgelassen werden sollten, sondern die Eigenschaft des übergeordneten Objekts. plotOptions.mfi.params ist ein Beispiel dafür, es schließt index aber keine index Eigenschaft oder extends ein Objekt, das dies tut, aber das übergeordnete plotOptions.mfi erweitert plotOptions.sma mit einer untergeordneten Eigenschaft plotOptions.sma.params Eigenschaft index die auf dem übergeordneten Element mit plotOptions.mfi.params . Ja, ich bin immer noch am Nudelholz, wie man damit umgeht. :) Scheint, als müsste ich den vollständig zusammengeführten Baum auswerten und die Typen von dort aus erarbeiten ...
• Viele generische Array , Object und Function Typen... wahrscheinlich alle gut in Beschreibungen dokumentiert, aber es scheint sich nicht in den Typen auszudrücken. Vielleicht wird dies durch ein vernünftiges Patchen der Typdaten behoben. Mein Favorit ist Array.<Array.<Mixed>> – noch keine Ahnung, was das ist. :)

Einige andere spezifische Dinge:

• Was sind die Typen Color , CSSObject und Mixed ? Color scheint ein formatiertes string , CSSObject ist ein Standardstilobjekt oder etwas Besonderes?
• series.bellcurve.data und series.histogram.data erweitern sich beide und erzeugen zirkuläre Bezüge. Ich denke, das ist nur ein Tippfehler, sie sind wahrscheinlich dazu gedacht, etwas anderes zu erweitern?

Außerdem fehlen einige Ihrer https://api.highcharts.com/highstock/plotOptions.bb.topLine.styles.lineColor. Wenn ich mich richtig erinnere, geben wir im Generator api-docs Raten ein, aber dies könnte in das Skript highcharts.jsdoc.js verschoben werden, damit es Teil von tree.json wäre.

@cvasseng Wie ist der Status unserer offiziellen TypeScript-Definitionen?

Habe ein Repo hochgeladen, um damit zu spielen , heute jedoch keine Ergänzungen.

Wenn ich mich richtig erinnere, tippen wir im api-docs Generator raten

Ich wäre neugierig zu verstehen, wie der Generator api-docs funktioniert. Es macht einen guten Job, aus dem API-Dump einen Sinn zu machen. Ich finde Dinge, bei denen ich nicht sicher bin, wie ich damit umgehen soll. Zum Beispiel series.bullet.data.targetOptions erweitert series.bullet.targetOptions , aber eine Definition für series.bullet.targetOptions existiert nicht... aber die Eigenschaften kommen in den Dokumenten gut durch. Ich denke, es liegt daran, dass series.bullet plotOptions.bullet das plotOptions.bullet.targetOptions , also wird series.bullet.targetOptions in plotOptions.bullet.targetOptions ?

Bearbeiten: Heute Abend ein kleiner Fortschritt, meine wahrheitsgetreue Prüfung auf den Standardwert hat alle wörtlichen false Werte verworfen, das wurde behoben und vieles mehr wird als Boolean abgeleitet. An manchen Stellen bin ich mir jedoch nicht sicher, ob boolean der richtige Typ ist. Ich überprüfe auch die values für wörtliche Typen (diese Informationen sind großartig!). Auf jeden Fall wird der Dump der

Habe einige Fortschritte gemacht, nachdem ich darüber nachgedacht habe, wie der Baum Objekte erweitert:

• Hat eine Methode entwickelt, um alle defs aufzulösen, die in einem bestimmten Pfad zusammengeführt werden . (Das hat mein Gehirn gedehnt ... ich stelle mir vor, der Docs-Generator macht so etwas?)
• Dann reduziere ich entferne , die andere defs, die aus anderen Teilen des Baums zusammengeführt wurden, überschatten, wodurch etwa 100 redundante Objekt-Defs und Hunderte von redundanten Eigenschaften entfernt werden. (Viele dieser "redundanten" Defs schienen dazu da zu sein, doc-Ergänzungen bereitzustellen, wie Beschreibung oder Standardwerte, aber halfen nicht den Typ-Defs ... klang es richtig?)
• Danach fehlten nur noch ein paar Defs im reduzierten Baum tatsächlich Typen, die nicht abgeleitet werden können, die ich hier patche (diese Änderungen wären wahrscheinlich im jsdoc selbst gut). Was übrig bleibt, kann alles abgeleitet werden ( siehe neueste "fehlende Typen" Dump ), obwohl ich nicht überprüft habe, dass der abgeleitete Typ immer korrekt ist. Es gibt auch noch das Problem der vagen Typen wie object , array und function .
• Hier ist ein Dump, wie der def-Baum geändert wird, bevor Defs vom TS-Typ ausgegeben werden. Dies gibt uns diese generierte Ausgabe, die beginnt, vielversprechend auszusehen.

Was kommt als nächstes

• Umgang mit ausgeschlossenen Feldern, von denen ich denke, dass ich eine Strategie habe, die Omit<> und einen Übergang macht, um explizit extends zu allen Objekten hinzuzufügen, die excludes (mit der in der erster Aufzählungspunkt) und Zurückwechseln, um Schnittstellen mit allen optionalen Eigenschaften zu verwenden. Ich denke, das wird funktionieren, solange wir sicher sein können, dass alle Eigenschaften optional sind? Gibt es erforderliche Eigenschaften?
• Einige andere Details : Typverbesserungen, Bereinigung und Tests
• Ich hole das nach den Feiertagen wieder ab. Würde mich über jedes Feedback freuen, wenn ihr denkt, dass dies überhaupt in die richtige Richtung geht oder nicht.

Fragen

• Was bedeutet "memberof": "yaxis" im tooltipValueFormat Doclet?
• Einer der context Werte ist PlotLineOrBand aber ich sehe das in den Klassendokumenten nicht, ist dies eine Unterklasse von Series ?
• plotOptions.series.states hat den Namen des Doclet-Typs "plotOptions.series.states" -- bedeutet das etwas Besonderes?

@aaronbeall hast du Fortschritte? Ich habe mich auch ein wenig mit der Typgenerierung für Highcharts beschäftigt.

Ein großer Fehler ist, dass das generierte tree.json nicht alle Typisierungen von Highcharts enthält, wie statische Methoden im Highcharts-Namespace. Es gibt 703 Symbole nach gültiger Symbolbereinigung. Aber danach sind die Ausgabesymbole in tree.json ungefähr 100. Das werden viele ignoriert.

@scott-ho Es ist ein bisschen her, dass ich das Projekt mit Highcharts im neuen Jahr verlassen habe, aber ich bin jetzt wieder dabei und werde bald wieder in dieses Projekt einsteigen.

Von meinem letzten Beitrag ging ich den Weg ein, type in interface umzuwandeln und extends anstelle von & (dies war meine Strategie, um die tree.json Verwendung von excludes bestimmter Felder) und stieß auf Probleme: TS erlaubt einer Schnittstelle nicht, eine andere Schnittstelle zu erweitern, die einen Feldnamen teilt, der ein Objekttyp ist, der zumindest nicht gemeinsam ist 1 Eigenschaft. Hier ist ein abstraktes Beispiel. Ich vergesse die genauen Beispiele dafür, auf die ich gestoßen bin, aber es gab viele, weil tree.json Objekte frei erweitert (in einigen Fällen überstiegen Erweiterungsketten 5) und Felder an jeder Stelle frei ausschließt. Dies führte mich zu der Annahme, dass mein bisheriger Ansatz, die Kreuzungstypen & verwenden, die beste Route sein könnte. Im Grunde führt dies dazu, dass einige Eigenschaften, die "ausgeschlossen" sind, im Typhinweis nicht wirklich ausgeschlossen erscheinen (weil sie von etwas höher im Baum erweitert werden, das nicht vom aktuellen Knoten weggelassen werden kann), aber ich kann nicht überlegen Sie sich einen besseren Weg, es zu tun. Die Dokumente umgehen dieses Problem, weil sie die Eigenschaften von einem einzigen Punkt aus rendern, aber strukturell können wir die Typen nicht auf diese Weise beschreiben, ohne extends und eine Menge meist doppelter Typdefinitionen zu erstellen.

Es gibt 703 Symbole nach gültiger Symbolbereinigung. Aber danach sind die Ausgabesymbole in tree.json ungefähr 100. Das werden viele ignoriert.

Welche Schnittmethode meinst du? Das war der schwierigste Teil...

Ja, mir ist auch aufgefallen, dass die Klassen/Namespaces nicht in tree.json (das beschreibt im Grunde die deklarativen Init-Optionen, wie ich sie verstehe), aber @cvasseng sagte, sie seien Vanilla jsdoc3, also können wir hoffentlich einen Standard verwenden Konverter dafür.

pruning wird von dieser Zeile aus verwiesen.

Die gesamte Datensammlung für tree.json der Methode publish .

Ich denke, es könnte einen Missbrauch der jsdoc-API geben.

Wir könnten einen besseren Weg finden, um eine neue Version von tree.json basierend auf der ursprünglichen Ausgabe von jsdoc zu generieren.

Heute habe ich eine Weile damit verbracht, herauszufinden, was die tree.json darstellen. Dann finde ich endlich heraus, dass tree.json nur die Arten von Diagrammoptionen hostet. Siehe hier https://api.highcharts.com/highcharts/.

Die Logik zum Sammeln und Generieren von Typen wird hier geschrieben - https://github.com/highcharts/highcharts/blob/master/tools/jsdoc/plugins/highcharts.jsdoc.js.

Möglicherweise müssen wir die Vollversion der Typen selbst generieren und etwas Ähnliches wie https://github.com/englercj/tsd-jsdoc tun

Gibt es dafür eine ETA? Die Definitionen in DefinitelyTyped sind ziemlich schrecklich.

Haben Sie darüber nachgedacht, mit dem TypeScript-Team über die fehlenden Funktionen zu sprechen, die Sie benötigen? Ich bin mir sicher, dass sie auf die Bedürfnisse eines Projekts von der Größe von Highcharts hören würden und sie haben einen ziemlich schnellen Release-Zyklus.

@aaronbeall Haben Sie sich die zugeordneten Typen angesehen ?

Hier ist ein Link mit einem Fix für Ihr Beispiel

@cvasseng @TorsteinHonsi

Haben Sie darüber nachgedacht, mit dem TypeScript-Team über die fehlenden Funktionen zu sprechen, die Sie benötigen?

@JannesMeyer Leider kein ETA- Omit<> funktioniert, um die Dinge auseinander zu nehmen ... , vollständige, ergonomische Typdefinitionen. Es scheint, als ob die Definitionen minimal definiert sein sollten (dh nicht die gleiche Eigenschaft auf ähnlichen Objekten überall neu definieren), aber ohne etwas zu verpassen. Wenn bei der Typvervollständigung eine Option angezeigt wird, die Highcharts in einem bestimmten Kontext nicht verwendet, ist das weniger ein Problem, als dass etwas fehlt, das vorhanden sein sollte. Es gibt auch das Problem des fehlenden Doc-Schemas, das zu generischen object oder any Typen führt ... irgendwo muss jemand den Typ aufschreiben, die Typgenerierung kann das nicht für Sie tun.

Ja, das macht Sinn. Es hört sich so an, als ob das Highcharts-Team TypeScript ein bisschen mehr annehmen sollte, als sie es derzeit tun. Vielleicht wäre es sogar möglich, die Dokumente aus Typdefinitionen zu generieren, anstatt sie aus jsdoc zu generieren?

@ JannesMeyer #8307 ist auf dem Weg, die vollständigen Arten von Highcharts zu generieren. Überprüfung ist erforderlich. Sobald die Docs-Verbesserung zusammengeführt wurde, wird ein weiterer PR ausgegeben, um die vollständigen Typen basierend auf der jsdoc-Notation automatisch zu generieren.

Ich habe diesen Beitrag verfolgt und es wird sehr hilfreich sein, wenn die Deklarationsdatei verfügbar ist.
Ich habe DefenitelyTyped für unser React/Typescript-Projekt verwendet. Ich blieb jedoch bei der Barrierefreiheit hängen. wusste nicht, dass der barrierefreie Teil mit DefenitelyTyped nicht funktioniert. Ich habe das Highcharts-Support-Team wegen meines Problems kontaktiert, aber noch kein Glück.
In unserem Team verwenden wir stark Highcharts/Highmaps. Deshalb haben wir darin investiert. Bitte denken Sie über die Priorität dieses Projekts nach.

Danke im Voraus!

Ich möchte nur mitteilen, dass dieses Thema hohe Priorität hat.

Das Highcharts-Team ( @sophiebremer und @oysteinmoseng ) nahm tatsächlich an einer Debugging-Sitzung mit mir teil und half mir, dieses Problem zu lösen, indem es die Js-Dateien direkt

Danke @sophiebremer , dies hat Priorität. Dies ist sehr nützlich für Projekte, die Typescript verwenden.

Hinweis: Ich habe den Kommentar bearbeitet, um einen besseren Kontext zu bieten und auch den Leuten vom Highcharts-Team zu danken.

Wir nutzen Highstock intensiv in einem großen Frontend-Team, das mit Angular / Typescript arbeitet. Es wäre großartig für uns, Typoskript-Definitionen zu haben, wir dachten, die Definitionen von DefinitelyTyped seien die Referenz, aber für Highstock ist es völlig veraltet.

Diese Typoskript-Definitionen ist wirklich ein großes Bedürfnis für uns!
Jede ETA ist willkommen :)

Wir arbeiten nun an der Qualität und versuchen die Anzahl der generierten Schnittstellen im Optionsbaum von Highcharts zu reduzieren. Danach starten wir eine öffentliche Beta-Phase.

Unsere ETA ist vorerst das 3. Quartal 2018 für die Beta.

@sophiebremer Das sind tolle Neuigkeiten! Haben Sie einen DTS-Generator oder verwenden Sie ein vorhandenes Konvertierungstool?

Wir verwenden ein benutzerdefiniertes. Wir haben den Ansatz dieses Pull-Requests https://github.com/highcharts/highcharts/pull/8307 mit dts-dom darunter ausprobiert, aber das hat nicht gut funktioniert.

Gibt es Neuigkeiten zu diesem? Es scheint, dass @types/highcharts nicht mehr aktualisiert wird.

Daran arbeiten wir nach wie vor mit hoher Priorität. Leider kann ich derzeit keine Vorschau der Erklärung veröffentlichen. Es gibt noch Typen, die konsolidiert oder eingeführt werden müssen. Die "highcharts.d.ts" wird eine riesige Datei mit mehr als 200.000 Zeilen Deklarationen und Kommentaren sein.

@sophiebremer wie produzieren Sie diese Datei? Manuell?

@scott-ho
Obwohl die Deklarationsdateien automatisch generiert werden, ist das Korrigieren und Aktualisieren der Doclets im Quellcode ein manueller Prozess.

Hallo allerseits! Ich habe eine Vorschau der Deklarationen für Highcharts in meinem persönlichen Repository veröffentlicht. Sie können es mit npm i https://github.com/sophiebremer/highcharts-declarations-alpha.git testen oder die Deklaration von https://github.com/sophiebremer/highcharts-declarations-alpha/blob/master/highcharts.d.ts herunterladen und direkt in ./node_modules/highcharts/ . Bitte teilen Sie uns mit, ob die Deklaration bei Ihnen funktioniert oder Probleme auftreten. Dankeschön!

Bekannte Probleme:

• Typ-Pinning in der Eigenschaft options.series funktioniert nicht. Die Umgehung besteht jetzt darin, das Objekt in Ihren Serientyp wie { data: [0, 1, 2]} as Highcharts.SeriesLineOptions umzuwandeln
• Stiloptionen sind nicht überall vom Typ CSSObject

ChartEventsOptions-Funktionen wie die Auswahl scheinen den Ereignisfunktionsparameter nicht zu berücksichtigen

Ein paar andere Probleme, die ich gefunden habe

• Die Export-, Offline-Export-Module können nicht importiert werden. Ich musste export = factory ändern, um die Standardfabrik zu exportieren und als Standardimport zu verwenden

• Modul für fehlende Anmerkungen

• PlotSeriesEventsOptions click muss als click modifiziert werden?: (e:PointerEventObject) => boolean;

Danke für das Feedback, @muperi !
Einige Anmerkungen zu deinem zweiten Post:

• Die regulären Module führen keinen Standardexport durch. Bitte überprüfen Sie Ihre tsconfig auf ES6-Einstellungen.
• Nur wenige Module haben noch Deklarationen. In den nächsten Monaten werden wir natürlich noch mehr hinzufügen.
• Wir werden dieses Problem untersuchen.

ChartEventsOptions-Funktionen wie die Auswahl scheinen den Ereignisfunktionsparameter nicht zu berücksichtigen

Fix ist Teil von highcharts/highcharts#9110 und wird im nächsten Update von https://github.com/highcharts/highcharts-declarations-beta enthalten sein.

Bitte fügen Sie diesem Repository weitere Probleme mit den Deklarationsdateien hinzu: https://github.com/highcharts/highcharts-declarations-beta.

Dankeschön.