Language-tools: Utilisez onwarn et d'autres options de svelte.config.js pour chaque outil

Les hommes sentent pour moi. J'imagine que la partie difficile sera de se mettre d'accord sur le nom / comment cela doit être spécifié exactement

Cela a du sens pour des choses comme les avertissements. Je ne suis pas d'accord sur le fait que tous les paramètres du serveur de langue doivent être lus à partir de celui-ci, il devrait être de la responsabilité de l'IDE de les fournir et de les intégrer au serveur de langue.

Donc, utiliser onwarn dans sa forme actuelle est une direction acceptable ?
Pour être compatible avec les configurations existantes, nous pourrions implémenter une interface de rappel onwarn similaire pour intercepter les avertissements, comme cela se fait actuellement dans les plugins svelte pour les bundlers.

La raison pour laquelle il n'y a peut-être pas tout, mais une certaine configuration pour le serveur de langue dans svelte.config.js est qu'au moins les options de format sont généralement configurées par projet. :pensée:

https://github.com/sveltejs/language-tools/tree/master/packages/svelte-vscode#sveltepluginsvelteformatenable

Les options de formatage doivent être placées dans un fichier .prettierrc car l'extension utilise plus joli en combinaison avec un plugin plus joli pour accomplir le formatage. https://www.npmjs.com/package/prettier-plugin-svelte

J'ai plus joli comme crochet de pré-engagement. La configuration est en package.json .

{
  "prettier": {
    "singleQuote": true,
    "printWidth": 80,
    "plugins": [
      "prettier-plugin-svelte"
    ]
  }
}

Y a-t-il quelque chose de spécial dans une invocation plus jolie du LS ? Ou il devrait charger cette configuration comme il le fait habituellement ? :pensée:

Cela fonctionnera aussi. Mon point était que les options de formatage ne devraient pas être la préoccupation de svelte.config.js .

Je suis d'accord, maintenant je ne vois rien d'autre que onwarn pour passer raisonnablement au svelte.config.js .

Il ne reste plus grand chose à décider.

Faire onwarn rappel de
Configuration unifiée compatible avec celle actuelle dans les bundlers.

Je suis plutôt préoccupé par l'ajout de la prise en charge de svelte.config.js à des choses qui ont déjà des mécanismes de configuration bien établis. Dans ESLint, par exemple, les plugins reçoivent simplement l'objet de configuration qu'ESLint a déjà chargé. Cela pourrait être le résultat de la fusion de plusieurs hiérarchique .eslintrc.js fichiers (ou des fichiers JSON, ou des fichiers YAML, ou le contenu des eslintConfig clés à package.json fichiers), et Je ne pense pas que ESLint indique au plugin où se trouvaient ces fichiers, donc je ne sais pas où le plugin devrait chercher svelte.config.js . Il existe une seule façon unifiée de gérer la configuration, et le noyau ESLint veut en être responsable.

La solution est donc :

1. Apprenez à mon client LS à lire les fichiers de configuration à partir de l'espace de travail et à transmettre la configuration au LS comme le fait svelte-vscode .
2. Importez la configuration de svelte.config.js et utilisez-la dans .eslintrc.js manière ou d'
3. Apprenez à svelte-check à charger la configuration depuis l'espace de travail.

On dirait que la seule chose qui mérite d'être modifiée est svelte-check alors ?

À part svelte-check , on a l'impression que c'est faisable dans l'espace utilisateur. :pensée:

Les candidats à l'harmonisation d'onwarn sont à mon avis : language-server, svelte-check, rollup plugin, webpack plugin.