Language-tools: Verwenden Sie onwarn und andere Optionen von svelte.config.js für jedes Tool

Männer spüren für mich. Ich stelle mir vor, der schwierige Teil wird darin bestehen, sich auf die Benennung zu einigen / wie genau sie angegeben werden soll

Es macht Sinn für Dinge wie Warnungen. Ich bin nicht der Meinung, dass alle Sprachservereinstellungen daraus gelesen werden sollten, das sollte in der Verantwortung der IDE liegen, diese bereitzustellen und in den Sprachserver zu integrieren.

Ist die Verwendung von onwarn in seiner aktuellen Form also akzeptabel?
Um mit bestehenden Konfigurationen kompatibel zu sein, könnten wir eine ähnliche onwarn-Callback-Schnittstelle zum Abfangen von Warnungen implementieren, wie es derzeit in schlanken Plugins für Bundler gemacht wird.

Der Grund dafür, dass vielleicht nicht alle, aber einige Konfigurationen für den Sprachserver in svelte.config.js ist, dass zumindest die Formatoptionen normalerweise pro Projekt konfiguriert werden. :Denken:

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

Formatierungsoptionen sollten in einer .prettierrc Datei abgelegt werden, da die Erweiterung hübscher in Kombination mit einem hübscheren Plugin verwendet, um die Formatierung durchzuführen. https://www.npmjs.com/package/prettier-plugin-svelte

Ich habe als Pre-Commit-Hook hübscher. Die Konfiguration befindet sich in package.json .

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

Gibt es etwas Besonderes in der schöneren Anrufung von der LS? Oder sollte es diese Konfiguration laden, wie es normalerweise tut? :Denken:

Dies wird auch funktionieren. Mein Punkt war, dass die Formatierungsoptionen nicht das Problem von svelte.config.js .

Ich stimme zu, jetzt sehe ich nichts anderes als onwarn um vernünftig zu svelte.config.js zu wechseln.

Es gibt nicht mehr viel zu entscheiden.

Klingt ein onwarn Callback in jedem Tool nach einer guten Lösung?
Einheitliche Konfiguration, die mit der aktuellen in den Bundles kompatibel ist.

Ich bin eher besorgt darüber, svelte.config.js Unterstützung für Dinge hinzuzufügen, die bereits über etablierte Mechanismen für die Konfiguration verfügen. In ESLint wird Plugins beispielsweise einfach das Konfigurationsobjekt übergeben, das ESLint bereits geladen hat. Dies könnte das Ergebnis der Zusammenführung mehrerer hierarchischer .eslintrc.js Dateien (oder JSON-Dateien oder YAML-Dateien oder des Inhalts der eslintConfig Schlüssel in package.json Dateien) sein und Ich glaube nicht, dass ESLint dem Plugin mitteilt, wo sich diese Dateien befanden, daher weiß ich nicht, wo das Plugin nach svelte.config.js suchen soll. Es gibt einen einzigen einheitlichen Weg für die Konfiguration, und der ESLint-Kern möchte dafür verantwortlich sein.

Die Lösung lautet also:

1. Bringen Sie meinem LS-Client bei, Konfigurationsdateien aus dem Arbeitsbereich zu lesen und die Konfiguration an den LS zu übergeben, wie es svelte-vscode tut.
2. Importieren Sie die Konfiguration von svelte.config.js und verwenden Sie sie irgendwie in .eslintrc.js . Erstellen Sie eine Liste mit Ignorieren und verwenden Sie sie in beiden Funktionen oder so.
3. Bringen Sie svelte-check bei, die Konfiguration aus dem Arbeitsbereich zu laden.

Sieht so aus, als wäre das einzige, was es wert ist, geändert zu werden, svelte-check dann ?

Anders als svelte-check fühlt es sich an, als wäre es im Userland machbar. :Denken:

Kandidaten für eine Harmonisierung von onwarn sind meiner Meinung nach: Sprachserver, Svelte-Check, Rollup-Plugin, Webpack-Plugin.