Language-tools: Documenter les composants avec une docstring qui apparaît sur la documentation de survol

Étant donné que cela pourrait également être utile pour les composants sans balise de script, je propose d'utiliser le commentaire HTML pour cela. svelte2tsx rechercherait alors les commentaires HTML commençant par une balise spéciale (comme @doc ) et placerait le contenu en tant que jsdoc au-dessus de l'exportation par défaut.

Des avis? D'autres idées ?

Je serais vraiment intéressé à essayer de mettre cela en œuvre. Cependant, je pense qu'il doit être conçu avec soin car c'est une fonctionnalité que certains développeurs utilisent _très souvent_ tous les jours.

Quelque chose qui me vient à l'esprit est :

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

Au début du fichier. Mais je pense que seuls les commentaires HTML fonctionnent, n'est-ce pas ?

De plus, peut-être pour le rendre plus similaire aux autres balises, j'ai l'impression qu'une balise <svelte:documentation> semblable à <svelte:head> pourrait être sympa, mais cela devrait être implémenté dans le compilateur.

Peut-être même <svelte:options documentation="blabla" /> ?

Cela nécessitera également un peu de travail dans le compilateur et l'approbation du référentiel principal. Les options ont été vérifiées par le compilateur.

J'ai créé un problème analogue sur le dépôt principal, voyons si nous pouvons parvenir à une conclusion :+1:

La moitié est terminée une fois que https://github.com/sveltejs/language-tools/pull/282 est fusionné. Le LSP n'affichait pas les chaînes de documentation en survol.

Maintenant, ce que je dois faire, c'est rechercher une docstring à partir d'un commentaire HTML @doc et l'ajouter à addComponentExport dans svelte2tsx.

@dummdidumm Actuellement, il n'est pas possible d'ajouter des docstrings aux exportations par défaut, car elles ne sont pas nommées :

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

Je suppose que, puisque les seules choses qui peuvent aller sur la portée racine de chaque fichier sont render et l'exportation par défaut, alors il est inoffensif de lui donner un nom générique comme Component ? Ou peut-être choisir parmi le nom du fichier ?

Oui, cela ne devrait pas poser de problème.

Est-ce que l'un de ces codes finit par faire partie du runtime d'une application, ou est-il uniquement là pour la prise en charge de l'outillage ?

Juste pour l'outillage.
À propos de cette exportation par défaut : nous devons vérifier comment cela affecte la saisie semi-automatique de l'importation.

Bon hum. Je ne comprends pas comment cela fonctionne actuellement. Si j'essaie de l'émuler dans un environnement TS uniquement comme celui-ci :

// Component.ts
export default class {}

Je n'obtiens pas de saisie semi-automatique pour Component sur d'autres fichiers, mais sur Svelte, cela fonctionne d'une manière ou d'une autre. Je devrais probablement lire le code connexe dans le LSP.

Quoi qu'il en soit, si je fais ceci à la place :

// Component.ts
export default class Component {}

Ensuite, j'obtiens des saisies semi-automatiques pour l'exportation par défaut en tant que Component sur d'autres fichiers. Je soutiens donc que le pari sûr est de nommer l'exportation par défaut de la même manière que le fichier, pour l'instant, puis de le tester en direct.

D'accord, j'ai donc essayé deux options, mais avec notre LSP, la seule chose qui fonctionne pour l'autocomplétion des importations de composants est :

export default class {
  // etc
}

Choses que j'ai essayé:

• Déclarer une classe puis l'exporter par défaut dans une autre ligne.
• Ajout du nom directement dans la ligne export default class Name .

~ Aucun d'eux ne fonctionne. Je regarde maintenant dans le fournisseur d'achèvement (https://github.com/sveltejs/language-tools/blob/master/packages/language-server/src/plugins/typescript/features/CompletionProvider.ts) pour voir où le le coupable est, car dans les environnements TS uniquement, j'obtiens des complétions pour les exportations par défaut des classes nommées, en fonction du nom de la classe.~

Mise à jour : déclarer une classe puis l'exporter par défaut dans une autre ligne fonctionne tant que le nom de l'export est le même que le nom du fichier. Je vais pour cette option.

Oui, l'achèvement de l'importation pour les composants sveltes contient du code supplémentaire, construisant essentiellement la suggestion d'importation. Peut-être que ce code peut être jeté si svelte2tsx a une exportation par défaut nommée qui est la même que le nom du fichier.

Corrigé via https://github.com/sveltejs/language-tools/pull/285