Language-tools: Dokumentieren von Komponenten mit einem Docstring, der in der Hover-Dokumentation angezeigt wird

Da dies auch für Komponenten ohne Script-Tag wertvoll sein könnte, schlage ich vor, dafür den HTML-Kommentar zu verwenden. svelte2tsx würde dann nach HTML-Kommentaren suchen, die mit einem speziellen Tag beginnen (wie @doc ) und den Inhalt als jsdoc über dem Standardexport platzieren.

Meinungen? Andere Ideen?

Mich würde die Umsetzung sehr interessieren. Ich denke jedoch, dass es sorgfältig entworfen werden muss, da es ein Feature ist, das einige Entwickler _sehr oft_ jeden Tag verwenden.

Was mir in den Sinn kommt ist:

/**
 * <strong i="6">@file</strong> Here is my documentation for this component
 */

Am Anfang der Datei. Aber ich denke, da funktionieren nur HTML-Kommentare, oder?

Vielleicht um es den anderen Tags ähnlicher zu machen, denke ich, dass ein <svelte:documentation> Tag ähnlich wie <svelte:head> nett sein könnte, aber das müsste im Compiler implementiert werden.

Vielleicht sogar <svelte:options documentation="blabla" /> ?

Das erfordert auch einige Arbeit im Compiler und die Genehmigung des Hauptrepos. Die Optionen wurden vom Compiler überprüft.

Ich habe ein analoges Problem im Hauptrepo erstellt, mal sehen, ob wir zu einer Schlussfolgerung kommen :+1:

Die Hälfte davon ist erledigt, sobald https://github.com/sveltejs/language-tools/pull/282 zusammengeführt wird. Der LSP zeigte beim Hovern keine Dokumentationszeichenfolgen an.

Jetzt muss ich einen Docstring aus einem @doc HTML-Kommentar beziehen und ihn zu addComponentExport in svelte2tsx hinzufügen.

@dummdidumm Derzeit ist es nicht möglich, Docstrings zu den Standardexporten hinzuzufügen, da sie nicht benannt sind:

export default class {
    $$prop_def = __sveltets_partial(render().props)
    $$slot_def = render().slots
}

Ich nehme an, da die einzigen Dinge, die in den Root-Bereich jeder Datei gehen können, render und der Standardexport sind, ist es harmlos, ihr einen generischen Namen wie Component ? Oder vielleicht aus dem Namen der Datei auswählen?

Ja das sollte kein Problem sein.

Ist dieser Code jemals Teil der Laufzeit einer Anwendung oder dient er nur der Werkzeugunterstützung?

Nur zum Werkzeug.
Über diesen Standardexport: Wir müssen prüfen, wie sich dies auf die automatische Vervollständigung des Imports auswirkt.

Richtig hm. Ich verstehe nicht, wie es derzeit funktioniert. Wenn ich versuche, es in einer Nur-TS-Umgebung wie folgt zu emulieren:

// Component.ts
export default class {}

Ich bekomme keine Autovervollständigungen für Component bei anderen Dateien, aber bei Svelte funktioniert es irgendwie. Ich sollte wahrscheinlich den zugehörigen Code im LSP lesen.

Wie auch immer, wenn ich das stattdessen mache:

// Component.ts
export default class Component {}

Dann bekomme ich Autovervollständigungen für den Standardexport als Component für andere Dateien. Ich unterstütze also die sichere Sache, den Standardexport vorerst gleich wie die Datei zu benennen und ihn dann live zu testen.

Okay, ich habe zwei Optionen ausprobiert, aber mit unserem LSP funktioniert das einzige, was für die automatische Vervollständigung von Komponentenimporten funktioniert:

export default class {
  // etc
}

Dinge die ich probiert habe:

• Eine Klasse deklarieren und dann als Standard in eine andere Zeile exportieren.
• Hinzufügen des Namens direkt in der Zeile export default class Name .

~ Beides funktioniert nicht. Ich schaue mir jetzt den Vervollständigungsanbieter (https://github.com/sveltejs/language-tools/blob/master/packages/language-server/src/plugins/typescript/features/CompletionProvider.ts) an, um zu sehen, wo die Schuld daran ist, dass ich in reinen TS-Umgebungen Vervollständigungen für den Standardexport von benannten Klassen erhalte, basierend auf dem Namen der Klasse.~

Update: Eine Klasse deklarieren und dann als Standard in eine andere Zeile exportieren funktioniert, solange der Name des Exports mit dem Dateinamen übereinstimmt. Ich gehe für diese Option.

Ja, die Importvervollständigung für schlanke Komponenten enthält zusätzlichen Code, der im Wesentlichen den Importvorschlag erstellt. Vielleicht kann dieser Code weggeworfen werden, wenn svelte2tsx einen benannten Standardexport hat, der dem Dateinamen entspricht.

Behoben über https://github.com/sveltejs/language-tools/pull/285